Re: [Ipsec] Layer 2 processing inside IPsec

[Jan Vilhuber <vilhuber@cisco.com>]

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
> Ipsec@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipsec
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec