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

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 protected]>
Date: Mon, Sep 29, 2008 at 5:45 PM
Subject: RE: [rohc] Comments on current RoHC over IPSec draft
To: Carl Knutsson <[email protected]>, Kristofer Sandlund
<[email protected]>
Cc: [email protected], "Robert A. Stangarone Jr."
<[email protected]>, [email protected],
[email protected], Tero Kivinen <[email protected]>, [email protected],
[email protected]


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 protected] [mailto:[email protected]] On Behalf Of
Carl Knutsson
Sent: Monday, September 22, 2008 6:49 AM
To: Kristofer Sandlund
Cc: [email protected]; Robert A. Stangarone Jr.; [email protected];
[email protected]; Tero Kivinen; [email protected]; Christou, Christos
[USA]; [email protected]
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 protected]> 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 protected]
> > https://www.ietf.org/mailman/listinfo/rohc
> >
_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc