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

Re: clarification

Marc,

>  >      Next Hdr          Next Hdr         Derived Port Selector Field
>  >      in Packet         in SPD           Value in SPD and SAD
>  >      ---------------   --------------   ----------------------------
>  >
>  >  3)  specific value,   specific value   NOT ANY (i.e., drop packet)
>  >      fragment
>  >
>  > 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.
>
> I found the above confusing.  I assume you meant that the *port* fields
> may not be available and that one might be able to identify them (only)
> in the first fragment.

That is correct.

> The protocol field is still there, the same for every fragment....

For IPv4 yes (assuming one isn't using Extension Headers in IPv4,
which is happening), for IPv6 maybe not, as the Next Hdr field in the
Fragmentation Header might not identify a transport protocol (e.g., it
could be Destination Options).

The mechanism used in the table to reject a packet for which the
protocol selector matched is to use the port selectors (since, as you
correctly point out, they are not always available) to force a
mismatch and thus reject an otherwise matching packet.

> I think we need to revisit the question as to the issue of dropping
> the fragments or not.  ...  but [filtering the first fragment and
> passing all others] does appear to be a valid IPSEC inbound SA
> behavior rule that an administrator may desire, yes?

Yes, and I would check to make sure that a product offered that
feature before buying; others may find the more limited functionality
specified in the document to be sufficient for their needs.

> Reading your note and the chart/document it would seem to state that
> any fragmented IPSEC message for a specific value would be dropped.

That is the way I read it, too.  [Nit: "IPSEC" is irrelevant here.]

> ... can't fragments of a TCP or UDP packet be individually tunneled
> through ESP (perhaps by a BITW or BITS implementation) to an end-host

Yes.

> I don't want those fragments dropped after authentication/decryption....
> Or, depending upon my security rules, maybe I do.

Agreed.

> So, for Case 3 I'd think that any of the following are possible when a
> specific-value for protocol on a fragment coming through an SA is specified:
>     "NOT ANY" (drop, we don't like fragments through this SA)
>     "ANY" (don't look for ports, whether there or not pass the fragment)
>     "actual port" (check if this fragment can contain them, else "ANY")

I do not think that the first two options would not require any code changes,
so would "only" impact product documentation.  I think that the third would
also require a code change for some vendors.  What do others in the working
group think about changing the minimum required functionality for fragments?

3a)  specific value,   specific value   NOT ANY (i.e., drop packet), or
       first fragment                   ANY (pass the fragmented packet), or
                                        actual port selector field

3b)  specific value,   specific value   ANY (pass the fragmented packet)
       other fragments

Charlie