Subject: Re: [Ipsec] Layer 2 processing inside IPsec

From: Jan Vilhuber <[email-masked]>
Date: Mon, 28 Jun 2004 10:25:47 -0700 (PDT)

On Mon, 28 Jun 2004, Bill Sommerfeld wrote:

> >     - ROHC requires that the lower layer not reorder packets, whereas
> >    IPsec includes replay protection with a sequence number, it does *not*
> >    put packets back into their original order on receive.
> >
> > I disagree: IPsec does not change the order
>
> That's not at all clear to me.
>
> > (so it can't have a negative effect) and more, it helps the
> > detection of reordering (by something else) and lost (i.e., it can
> > have a positive effect).
>
> No, it seems perfectly clear.
>
> IPsec runs over IP, which is allowed to reorder packets.
>
> ROHC runs over link layers which are not allowed to reorder packets.
>
> Unless you have some impossible-to-obtain-in-general out-of-band
> knowledge that an IPsec tunnel will only traverse links *and* routers
> which never reorder packets, you cannot naively use ROHC over IPsec.
>

isn't that perfectly acceptable, though? There are situations where
people KNOW exactly where their data is going. You can always build
another layer AROUND the IPsec+ROHC layer to make sure packets get put
back into some sort of order first, before handing them up the
stack. That's not the job of the packet-definition, after all. We can
provide a document that described how to put the two together, with
adequate warnings, and leave the rest up to a follow-on document.

I admit not being very ROHC savvy. I've been concentration on IPHC, or
better yet, ECRTP, which CAN run over the internet at large just fine,
and can be used to mitigate some of the packet expansion caused by
ipsec itself.

> An integrated IPsec - ROHC implementation could look at the IPsec
> sequence number and insert its own reorder buffer, but such an
> integration would not be as simple as defining an IP protocol number
> for ROHC.
>

Agreed. But you could certainly build on that. BTW: I vote for an IP
protocol number for IPHC in GENERAL (of which ROHC could/would be a
subtype).

jan

> >     - ROHC changes the encoding of header fields which are used for
> >    access control purposes by IPsec (inner tunnel headers, payload
> >    protocol, and transport-layer ports); a naive integration of ROHC
> >    inside IPsec would bypass IPsec's post-decryption access controls.
> >
> > I believe you refer to RFC 2401 section 5.2.1 steps 2 and 3.
> > Obviously the decompression must be integrated, i.e., done just after
> > decryption and before sanity post-decryption checks. BTW the checked
> > fields are likely not transported in packets but taken from the
> > decompression context. IMHO this is an implementation issue more
> > than a real problem.
>
> It's an architectural issue.  An integrated IPsec-ROHC means that the
> ROHC would have to be inserted into the *middle* of IPsec processing,
> between the policy enforcement part and the encryption part.
>
> Again, not so simple as merely defining an IP payload number for ROHC.
>
> 						- Bill
>
>
> _______________________________________________
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec
>

 --
Jan Vilhuber                                            [email-masked]
Cisco Systems, San Jose                                     (408) 527-0847

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

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 28 Jun 2004 10:21:19 -0700 (PDT)

On Sat, 26 Jun 2004, Francis Dupont wrote:

>  In your previous mail you wrote:
>
>    Does any one know if such a mechanism was proposed ?
>
> => look at draft-vilhuber-hco{ip,esp}-xx.txt

I bet these have long since expired, but I'd be happy to resubmit them
(as individual submissions). When I first submitted these, there flood
of responses and comments was astounding. I got one single email about
it all (saying essentially "Cool.. I like it and have been thinking
along similar lines"; I think that might even have been you, francis :).

Is the IETF now interested in this thing? Previously, comments (in
other working groups and other documents) were basically "Why would we
want to do this?" (which to me seems obvious, of course).

> This is also a goal of the MOBIKE WG.
> BTW I believe we can do more in the ESP tunnel context than in the
> standard one, for instance class more header fields as "static"
> and reuse the SPI as a context number...

I agree completely. There's also ways to get rid of checksums at the
IPHC layer, and rely on the one from IPsec, allowing us to cut down
even MORE on the size of the compressed header.

> Can we continue offline?

I'm game if you want to include me on a private exchange. I still have
the drafts, and we can use them as a start, if you like.

jan

> Thanks
>
> [email-masked]
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Jul 2004 10:15:19 -0400

At 8:10 PM +0200 6/30/04, [email-masked] wrote:
>I summarize hereafter the main points that arise from the different messages
>posted to this list :
>   - Combining ROHC (or whichever generic compression frameworks suits) and
>IPsec in an efficient way leads to an integration of ROHC in the middle of
>IPsec. From the IPsec framework point of view, this could take the form ESP
>used in tunnel mode, but with a specific "next header" value different from
>"IP", in order for the policy enforcement processing to take place just
>after decryption and decompression, along the lines of what Jan Vilhuber
>proposed.

tunnel mode requires that the next header be IP (v4 or v6) because 
that header is used for the access control checks. So I don't 
understand your description above.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 2 Jul 2004 13:52:03 -0400

At 10:33 AM -0700 7/2/04, Paul Lambert wrote:
>  >tunnel mode requires that the next header be IP (v4 or v6)
>
>Requireing the next header to be IP is just one type of access 
>policy.  There is no reason that an access policy could not allow 
>other protocols and process/filter them accordingly.
>
>Paul
>
>-

There is a requirement for an IPsec TUNNEL to have an inner IP 
header, because of the need to forward the inner packet based on that 
header, and because our access control checks are defined relative to 
IP and next layer headers. if there is no need to forward the packet 
based on an inner IP header, then transport mode is used, and the 
access controls are applied to the outer header.

Steeve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Jul 2004 12:22:49 -0400

At 1:31 AM -0700 7/5/04, Paul Lambert wrote:
>Two interesting examples of non-IP next protocols are carring L2 traffic
>on ESP or onion-routing where it's handy to carry ESP on ESP.  In both
>cases the end addresses are inside the tunnel, they just are not 'next'.
>In both cases, they are clearly not the final end-system, so they are
>not transport mode.

Paul,

I think you have failed to take note of the changes to the transport 
mode description that are in 2401bis. We explicitly allow transport 
mode for overlay nets and the like, and explain how to deal with 
traffic in this context. So, my comments stand.

Steve