Subject: [rohc] RE: draft-ertekin-rqts-hcoipsec-01.txt

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Sun, 19 Jun 2005 20:41:44 +0200

> I am concerned that there might me some disconnect between 
> RFC 2401 (and the approved RFC 2401bis) and ROHC.  This
> document seems to be the place where the two come together.

Yes, true, but you have to help us HC-guys understand the
"new" environment we are now considering applying HC on top
of.

> >* How much work would be required to incorporate HC negotiation
> >   into IKE? I notice the example of what would be negotiated for
> >   ROHC, and there is at least one important parameter missing,
> >   the "PROFILES" set supported.
> 
> IKE already supports negotiation of payload compression.  IPCOMP is a 
> property that is negotiated.  I have not looked too deeply, 
> but this seems to be compress prior to encrypt.
> 
> >* To allow packets with either compressed or uncompressed
> >   headers to traverse a single SA, would the ROHC uncompressed
> >   profile not do the job there? Then you can avoid unnecessary
> >   multiplexing overhead from being added to all packets.
> 
> This is not allowed!  The processing should be the same for 
> all of the packets on the SA.  IKE establishes the rules for
> the SA, and then the processing associated with RFC 2401
> (and the approved RFC 2401bis) enforces those rules.  As I
> read it, header compression would need to be on or off 
> for all packets associated with a particular SA.

I do not mean that you turn off ROHC, but what if you get more
flows to handle than you have negotiated support for, then there
is a ROHC profile that can send the packets "ROHC-encapsulated"
but with uncompressed headers. This profile can also be used for
e.g. packet flows using "new" transport protocols not yet supported
by ROHC.

In the draft, I saw multiplexing of compressed and uncompressed 
header packets, and therefore I wanted to point out that this
multiplexing can be done with ROHC mechanisms, thereby avoiding
the unnecessary overhead from an additional multiplexing mechanism.

> >* In 5.2.3, it should be mentioned that ROHC clearly does not
> >   need a packet type identification mechanism.
> 
> I do not see how the IPsec processing can be done without packet type 
> identification.  How does one determine when to apply header 
> compression and when to skip it?

I do not understand this comment. If you set up a tunnel where you
want to apply HC, you intend to compress all packets, right? Then
you will only have ROHC-packets in the tunnel, no packet type
identifier is then needed.

> >* From 5.2, to me it looks like a) will be covered by a general
> >   effort to do an enhanced ROHC that e.g. addresses reordering.
> >   However, b) and c) would require a new work item to be started
> >   for "HC over IPsec SA".
> 
> Is there a need for HC over ESP over HC?

What do you mean here? I do not see how this question was a 
response to what I wrote above. Who is talking about anything
else than "HC over IPsec", which is the title of the draft being
discussed, right? 

Rgds,
/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Stephen Kent <[email-masked]>
Date: Fri, 24 Jun 2005 09:58:24 -0400

Lars-Erik,

>...

I'm not sure I understand your comment above. When we create an SA we 
define the range of traffic flows that it will accommodate, based on 
the 5 traffic selector types that IPsec uses to distinguish traffic 
(S/D IP address, protocol, and S/D ports, if applicable). Only 
traffic consistent with the traffic selector values specified for an 
SA can be carried on that SA, period.

>the unnecessary overhead from an additional multiplexing mechanism.

The draft you cited is an individual submission. It was not 
coordinated with the IPsec WG. It addresses the IPsec requirement for 
inbound traffic demuxing by adding another layer of header, but this 
has the potential to consume too many protocol numbers, and thus may 
not be acceptable. There is also the issue that mixing compressed and 
uncompressed traffic on the same SA, and distinguishing them via the 
presence of an added protocol layer may cause problems for inbound 
processing, because support for nested processing is an optional 
feature for IPsec implementations.

>...

See section 5.2 of 2501bis (now in the RFC editor's queue) for an 
explanation of how inbound traffic is processed in IPsec. It may be 
OK to handle HC-compressed traffic as you suggest, but it is not 
immediately clear that this will work, because of the underlying 
assumptions that IPsec makes in support of access control.

Steve