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

Re: clarification



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
 > 
  . 
  .
  .
 > 
 > 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.

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.  The protocol field is still there, the same for
every fragment....

I think we need to revisit the question as to the issue of dropping
the fragments or not.  I've seen firewalls on the network today which
drop the first fragment based on ports (or check/avoid the subsequent
re-mixed fragments that try to by-pass the port checks) and yet they
allow the later fragments in, safe(?) in the knowledge that properly
functioning stacks will never reassemble a packet that has been denied
access by dropping the zero'th fragment.  I make no comment as to
whether this is optimal behavior but it does appear to be a valid IPSEC
inbound SA behavior rule that an administrater may desire, yes?

Reading your note and the chart/document it would seem to state that
any fragmented IPSEC message for a specific value would be dropped.  I
don't believe this is the case, can't fragments of a TCP or UDP packet
be individually tunnelled through ESP (perhaps by a BITW or BITS
implementation) to an end-host, for example?  I don't want those
fragments dropped after authentication/decryption....  Or, depending
upon my security rules, maybe I do.

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")

Comments?
                        
                         
   -- Marc --



Follow-Ups: