Re: AD comments on draft-ietf-rohc-hcoipsec-10

Hi Magnus,

Thanks for your comprehensive review of our documents.  Please find
below our response to your comments.

> Hi,
> 
> I have now reviewed the three documents in the ROHC over IPsec
> solution.
> I will comment here on some high level issues that may require
document
> updates, however not necessarily in this document. Please consider if
> the fix is more appropriate in any of the other two documents.
> 
> 1. I find there is a lack of discussion of how to handle Path MTU for
> these ROHC inside of a IPsec SA. The issue to me is the variable size
> compressed packet. That makes the actual MTU seen on the ingress of
the
> processing to jump up and down depending on what type of ROHC packet
is
> created for a particular packet. To me it appears that the MTU with
> ROHC
> enabled in a IPsec SA is less than without ROHC when sending IR.
> 
> There must be some discussion about this issue. How it affects path
MTU
> discovery, what to do about it so that one don't get spurious IP
> fragmentation or MTU losses for packets with DF bit set.

Thanks for starting a thread on this on the tsv mailing list.  We will
provide our thoughts on the other email thread.
 
> 2. I understand that one the negotiation mechanism is sufficient to
> ensure that the decompressor doesn't get a profile or more CID then it
> can handle. However, wouldn't it be suitable to recommend at least
some
> basic set of functionality that is mandatory to support to ensure
> better
> interoperability and minimal achieved functionality.

We could update the drafts to specify a "minimum mandatory set of
capabilities" that a compressor/decompressor must support.  However, the
motivation for not specifying this "minimum mandatory set of
capabilities" is that we wanted to remain consistent with traditional
hop-by-hop ROHC specs/implementations.  I took a look at RFCs 3095 and
3241, and these do not specify a minimum set of profiles, CIDs, etc., a
ROHC instance must support.  The ROHC/PPP only suggests values for these
parameters (similarly, we suggest values for these parameters in our
drafts).

Correct me if I a wrong, but I think that the only mandatory capability
is the uncompressed profile...and the utility of this profile is limited
in the context of ROHCoIPsec.

Presumably, with all the other pre-configurations (e.g., SPD) that are
required between two IPsec implementations to get an SA up, we can
mitigate the interoperability concerns that you allude to through this
pre-configuration process (e.g.,  simply synchronize ROHC parameters
between two IPsec implementations).  Therefore, I would like to leave
the drafts as-is, but I am open to further discussion.

> 3. When I read this document I get the impression that it would be
> suitable to be published as a proposed standard because it defines so
> much how things shall interact. So can you please motivate why you
> think
> Informational is more suitable?

Back when we started this draft, we intended it to be a informational
requirements document.  Over time, the requirements flavor changed, but
the general intent is still the same, i.e., to provide some
background/guidance for the IKEv2 and IPsec drafts.  

> 4. Section 6.
> 
> The Next Header field of the security protocol header
>    (e.g., ESP, AH) is populated with a "ROHC" identifier,
> 
> Considering that you are having so much other references, why not a
> reference to where this one is defined? Also should it not say: ...
> "ROHC" protocol number?

Agree.  I will update the draft accordingly.

BR,
Emre