Subject: [rohc] AD comments on draft-ietf-rohc-hcoipsec-10

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 May 2009 18:08:57 +0200

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.

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.

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?

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?

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 16 May 2009 21:11:20 +0200

> fragmentation or MTU losses for packets with DF bit set.

Magnus,

thank you for the quite thorough review of the ROHCoIPsec documents.

Let me focus on this one comment right now as it is quite dear to my  
heart.
I definitely agree that the MTU variability caused by header  
compression merits discussion.
(I'm just now running into a different manifestation of it in 6lowpan.)

I'm just not sure the discussion should be done as part of ROHCoIPsec.
There are other applications of header compression in tunnels, e.g.  
4901, 4170.
As I mentioned, adaptation layers also might run into problems here;  
I'm not even sure basic ROHC (3095/5225) is immune to this problem if  
there are relevant MTU restrictions coming from L2 (normally, PPP has  
a larger MTU than Ethernet and so we just don't notice).

I'd prefer to have this discussion in a more general form.
This would probably involve (PL)PMTUD experts and HC experts, both  
from ROHC and maybe from INT WGs such as 6lowpan.
Clearly, there is enough related work about tunnels in TSVWG right now.

I would change my mind if there was something specific that ROHCoIPsec  
can do that does not apply to the other versions of this issue, but  
right now I'm lacking imagination what that could be.

Gruesse, Carsten

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 May 2009 15:21:25 +0200

Carsten Bormann skrev:
> Let me focus on this one comment right now as it is quite dear to my heart.
> I definitely agree that the MTU variability caused by header compression
> merits discussion.
> As I mentioned, adaptation layers also might run into problems here; I'm
> not even sure basic ROHC (3095/5225) is immune to this problem if there
> are relevant MTU restrictions coming from L2 (normally, PPP has a larger
> MTU than Ethernet and so we just don't notice).
> 
> This would probably involve (PL)PMTUD experts and HC experts, both from
> ROHC and maybe from INT WGs such as 6lowpan.

Carsten,

I agree that this is a generic issue that do occur for both header
compression and any tunnel technology that has a variable overhead.
However, ROHCoIPsec do have a few special issues that brings these
issues to the forefront.

- Turns of the usage of ROHC segmentation that could be used for dealing
with this issue. However, I think turning off segmentation is the right
choice but forces us to deal with the resulting PMTUD problem.

- That we have noticed it in this case. I don't find it acceptable to
punt on the issues just because it should have been dealt with earlier.

So yes general discussion is good as it is a generic issue. However,
this document set needs to both document it and have some consideration
on what to do with it.

I will try to start a discussion on this across some WG and area lists
and hold the discussion on TSV-area.

Cheers

Magnus Westerlund

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 May 2009 02:43:35 +0200

On May 18, 2009, at 15:21, Magnus Westerlund wrote:

> some consideration

So what would you want the compressor to do?
Run PLPMTUD (probes can be done by occasionally compressing badly*) on
the tunnel and reject (ICMP unreachable/Frag needed) all DF/IPv6
packets that would not fit with worst-case expansion?
Probably safe, but somewhat expensive.

Gruesse, Carsten

*) Yes, this needs way more text.
You would need to compress badly whenever compressing a packet that,  
badly compressed, would not fit the currently established safe PMTU.   
That unfortunately tends to shrink while compressing well, which ROHC  
tends to do :-)

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 May 2009 10:42:34 +0200

> That unfortunately tends to shrink while compressing well, which ROHC

Please join the discussion on the TSV-area list. It at least got the
attention of some TCP folk, but I think there needs to be some ROHC
input into this discussion also.

cheers

Magnus Westerlund

---

From: Carl Knutsson <[email-masked]>
Date: Tue, 19 May 2009 11:40:17 +0200

Magnus, Carsten, all

I raised the issue about the MTU variability during the last-call when
it was suggested to remove ROHC segmentation. ROHC segmentation was
presented as the solution the first time it was discussed on the list.
Unfortunately Chris's email didn't turn up on the rohc-list. I can't
find it in the archive. But at least my answer did. You can find the
whole conversation below.

ROHC segmentation doesn't handle reordering very good, so we all agreed
to remove it. The overhead depends on the implementation and the
negotiated profiles. The solution was to add the worst case to the PMTU.
At the time we found the solution acceptable. I am not sure about the WG
as a whole since they may have been left out of the loop. It is my
responsibility to make sure the information is sent to the list. I
didn't realise this until now. So starting this discussion in the WG
again is probably a good thing.

RTP profile can in worst-case add up to around 20 bytes. Header
compression works best for small packets. Large packets that doesn't fit
the MTU because of the overhead could be sent uncompressed or over a
channel without ROHC. The overhead for the uncompressed profile is only
a few bytes. This overhead is added to the PMTU field.

/Calle

---------- Forwarded message ----------
From: Christou, Christos [USA] <[email-masked]>
Date: Mon, Sep 29, 2008 at 5:45 PM
Subject: RE: [rohc] Comments on current RoHC over IPSec draft
To: Carl Knutsson <[email-masked]>, Kristofer Sandlund
<[email-masked]>
Cc: [email-masked], "Robert A. Stangarone Jr."
<[email-masked]>, [email-masked],
[email-masked], Tero Kivinen <[email-masked]>, [email-masked],
[email-masked]

Carl,

As we discussed, Emre and I are thinking not to include MRRU. First, the
IPsec process MUST implement PMTU. Here is what RFC 4301 states:

  "When an IPsec implementation receives an unauthenticated PMTU
  message, and it is configured to process (vs. ignore) such messages,
  it maps the message to the SA to which it corresponds.  This mapping
  is effected by extracting the header information from the payload of
  the PMTU message and applying the procedure described in Section 5.2.
  The PMTU determined by this message is used to update the SAD PMTU
  field, taking into account the size of the AH or ESP header that will
  be applied, any crypto synchronization data, and the overhead imposed
  by an additional IP header, in the case of a tunnel mode SA."

Therefore, in the case of RoHCoIPsec, we were thinking that this
requirement be simply amended to state that "the PMTU determined by this
message is used to update the SAD PMTU field, taking into account the
size of the AH or ESP header that will be applied, any crypto
synchronization data, the overhead imposed by an additional IP header
(in the case of tunnel mode SA), and the additional fields added by
RoHC."  If IPsec properly accounts for the additional fields that could
be added on by RoHC , then packets will not be processed by the RoHC
module that could exceed PMTU since the IPsec module would drop packets
that do not match the SPD PMTU policy (regardless of the profile).  As a
result, I am not sure how segmentation is applicable.

As you have pointed out, the overhead varies based on profiles. Although
it might not be as ideal, the overhead we would account for PMTU could
be profile dependent. In other words, there will be an entry in the SPD
for the profiles we would like to compress over particular SA's.
Therefore, depending on the profiles identified, we could account for
the maximum possible RoHC overhead in the PMTU calculation based on the
profiles listed in the SPD.

We will not include the MAX_HEADER parameter in our drafts.

We can update our IPsec and IKE extensions drafts accordingly...

Thanks,

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Carl Knutsson
Sent: Monday, September 22, 2008 6:49 AM
To: Kristofer Sandlund
Cc: [email-masked]; Robert A. Stangarone Jr.; [email-masked];
[email-masked]; Tero Kivinen; [email-masked]; Christou, Christos
[USA]; [email-masked]
Subject: Re: [rohc] Comments on current RoHC over IPSec draft

Emre,

I believe MRRU should stay. I think we should have very good reasons
before we remove it. We should not make any assumptions about the link
layer. For some users it may more be convenient to use the ROHC
segmentation instead of fragmentation in other layers. Why would we not
allow it? Both the ROHCoIPSec draft and the framework already discusses
ROHC segmentation. The ROHCoIPSec drafts is quite clear about the
disadvantages with ROHC segmentation.

I agree with Robert that the MAX_HEADER parameter should be removed.
We have agreed on a set of negotiation parameters for the ROHC framework
(RFC 3095 and RFC 4995). All other parameters must be negotiated within
the protocol. If the MAX_HEADER parameter is really needed, it should be
included in the ROHC framework and not in ROHCoIPSec drafts. If it
becomes a problem for future ROHC profiles, it could be solved by
something similar to CONTEXT_MEMORY feedback option for v2.

/Calle

On Mon, Sep 22, 2008 at 9:46 AM, Kristofer Sandlund
<[email-masked]> wrote:
> >
> > Ertekin, Emre wrote on :
> >
>>> >>> MRRU - This parameter is unnecessary. The external interface of the
>>> >>> IPSec device should be able to determine the MTU of its link and
>>> >>> fragment as needed/necessary. None of the RoHCv2 PROFILES (found in
>>> >>> RFC 5225) allow for the use of MRRU, so why use it?
>> >>
>> >> Fair comment.  We'll remove this parameter.
> >
> > Hi,
> >
> > I haven't read the drafts in question nor the entire mail I'm replying

> > to, I'd just like to point out that the statement above is incorrect.
> > The following is a quote from 5225:
> >
> >   The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of
> >   [RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU)
> >   MUST be set to 0, if the configuration of the ROHC channel contains
> >   at least one ROHCv2 profile in the list of supported profiles (i.e.,
> >   the PROFILES parameter) and if the channel cannot guarantee in-order
> >   delivery of packets between compression endpoints.
> >
> > Therefore, it *is* allowed to use ROHC segmentation in v2, it is only
> > disallowed if you have a reordering channel with v2 profiles.
> > I'm not saying that ROHC segmentation is a very useful feature or that

> > you have to allow it, I'd just like to avoid you making decisions
> > based on an assumption that v2 *always* disallows segmentation.
> >
> > /k
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/rohc
> >
_______________________________________________
Rohc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 May 2009 13:03:45 +0300

> a few bytes. This overhead is added to the PMTU field.

With ROHC over IPsec there is already a way to express uncompressed
packets without any overhead (i.e. if next header is ROHC protocol
then packet is compressed with ROHC, if not then it is uncompressed),
so sending uncompressed packets does not add any more overhead than
what IPsec already adds.

The amount of overhead for IPsec is per SA, as it depends on the
protocol (ESP/AH) and about the algorithms selected for that SA, so
adding ROHC overhead there should be easy. The ROHC overhead should
take account the normal ROHC maximum header expansion and the ROHC ICV
length.
-- 
[email-masked]

---

From: "Ertekin, Emre [USA]" <[email-masked]>
Date: Tue, 19 May 2009 18:25:25 -0400

Hi Magnus,

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

> 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.
 
> 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.

> 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.  

> reference to where this one is defined? Also should it not say: ...

Agree.  I will update the draft accordingly.

BR,
Emre

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 May 2009 11:05:29 +0200

> the drafts as-is, but I am open to further discussion.

Okay, I can see us continuing on this track.

> background/guidance for the IKEv2 and IPsec drafts.  

I think I am primarily worried about the part in the document that
discusses the need for two SAs and how data is triaged between the ROHC
and non-ROHC one. This is in my eyes normative parts of the solution. It
is the text in Section 6.1 that sounds my alarm bells on this topic.

A lot may be obvious but isn't it part of the technical solution that
makes ROHC over IPsec work? I know we are in a grey area here.

Cheers

Magnus Westerlund