[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: clarification
Paul,
> Conceptually, IPSEC lives above IP, just like UDP or TCP do.
> Reassembly is an IP layer function, so clients of IP (such as UDP, or
> IPSEC) see fully assembled packets. Fragments don't appear on that
> abstract interface at all, so it's not really meaningful to talk about
> what you're required to do when you see them.
I didn't get the point of this. I thought we were discussing what
happens *within* something like an ESP tunnel mode packet when its
actually carrying an IP fragment? Once a fragmented ESP packet is
reassembled by IP and presented to your "IP client" IPSEC code what
happens when there is a tunnelled IP fragment found after decryption?
Do you reinsert it back into IP processing as if it came in "off the
wire"? Or apply selection criteria in the context of the SA that this
IP fragment came from?
>
> In addition, the interface from IPSEC to IP is an internal interface.
> Internal interfaces are generally not subject to standardization
> (unless you're talking about an API spec). Stating properties of such
> interfaces as requirements is confusing.
True, but I'm not talking about interfaces nor standardizing them.
Just system behavior. If there's a statement in an IPSEC architecture
document that implies fragmented packets arriving *within* an ESP/AH
tunnel are to be discarded then I would think senders shouldn't waste
their time to send them. :-) But we do allow senders (hosts or
gateways) to tunnel fragments within an unfragmented (or fragmented)
IPSEC ESP packet. And the "discard" statement is apparently not a MUST
or conformance requirement so I think we're OK, for now.
-- Marc --