[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clarification



>>>>> "Marc" == Marc Hasson <mark@mentat.com> writes:

 Marc> Charlie,
 >> Next Hdr Next Hdr Derived Port Selector Field in Packet in SPD
 >> Value in SPD and SAD --------------- --------------
 >> ----------------------------
 >> 
 >> 1) ESP ESP or ANY ANY (i.e., don't look at it)
 >> 
 >> 2) -don't care- ANY ANY (i.e., don't look at it)
 >> 
 >> 3) specific value, specific value NOT ANY (i.e., drop packet)
 >> fragment
 >> 
 >> 4) specific value, specific value actual port selector field not
 >> fragment
 >> 
 Marc> .  .  .
 >>  Otherwise in case 3), if the IP packet is a fragment and the SPD
 >> requires an explicit protocol, then one cannot say that the packet
 >> is for that protocol, and the packet must be dropped.  Note that
 >> in the case of the first fragment, one might be able to identify
 >> the protocol.  However, since the rest of the fragments will be
 >> dropped, there is no point in letting the first one pass through.
 >> In addition the first fragment typically has the most useful
 >> information in it, if it is to be audited, so rejecting it
 >> immediately may produce more meaningful diagnostics.

 Marc> I found the above confusing.  I assume you meant that the
 Marc> *port* fields may not be available and that one might be able
 Marc> to identify them (only) in the first fragment.  The protocol
 Marc> field is still there, the same for every fragment....

I found the discussion on fragment handling in IPSEC to be problematic 
for a different reason.

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.

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.

The required behavior applies to observable interfaces -- wires coming 
out of the box.  It is perfectly valid to say that incomplete packets
don't make it through a security gateway.  But I'd prefer not to see
that described in the current terms.

	paul


References: