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

RE: diffedge handling of fragments

Michael,
Section 4.4.2 of RFC 2401 also says that if the port information is not
available in a fragment it is to be discarded.  The exact text is as
follows:

        If the packet has been fragmented, then the port information may
        not be available in the current fragment.  If so, discard the
        fragment.  An ICMP PMTU should be sent for the first fragment,
        which will have the port information.  [MAY be supported]

I'm not sure that sending a fragment over a host<->host SA would always be
the best course of action.  The host<->host SA might not provide the
required security for the fragment.

Sumit A. Vakil
Caly Corp

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
>   If a non-initial fragment arrives at a marking point (i.e. 
> at the entry
> point to a diffserv cloud), and no previous initial fragment has been
> received for that (destination,fragmentID), should the fragment be:
> 	 1) delayed until an initial fragment arrives (how long?)
> 	 2) sent with best effort 
> 	 3) dropped
> 
>   In the pathological case, the fragment offset is such that 
> one has to
> reassemble the packet in order to make the MF classication decision. I
> believe that in these cases it may be prudent to drop the 
> fragment as it may
> simply be an attempt to do a denial of service attack.
>   Otherwise, #3 is evil, as it causes outages that are very 
> hard to debug.
>   #1 turns into #3 if there is no timer involved.
> 
>   One possibility is to send it with best effort, *and* queue 
> it for a period
> such that it gets sent with the appropriate flag. 
>   
>   Two notes:
>   1. I don't think that IPsec has yet to agree on anything 
> specific to say
>     about this particular case other than noting that the 
> TCP/UDP ports may
>     be "OPAQUE" in section 4.4.2 of RFC2401. This hasn't been 
> an issue since
>     most deployment has so far involved subnet<->subnet or 
> host<->host and not
>     port<->port SAs done by a security gateway. For IPsec, 
> replace #2 with
>     "sent with a host<->host SA"
>   
>   2. RFC2205 (RSVP) specifically says on page 8:
>   
> 
>       "1.   It is necessary to avoid IP fragmentation of a 
> data flow for
>             which a resource reservation is desired."
> 
>   So, this would argue also for #2.
> 
> ] Train travel features AC outlets with no take-off 
> restrictions|  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON  
>   |net architect[
> ] mcr@sandelman.ottawa.on.ca 
http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");
[


  
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.5.4, an Emacs/PGP interface

iQB1AwUBN/sckI5hrHmwwFrtAQH+JgL+NbVcRLefglM05IjaKrfYA+ZisLogy2HO
76ZscNfd6Ywfjm/0RsKWs/Aut6IA48APi5Z/u7i6PSJ2pZ75NmhlWdUw/YbygclS
/ksmxfvhFmPzolGIMJxj4MbPGD4OM3sF
=+8wL
-----END PGP SIGNATURE-----
Follow-Ups: