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

diffedge handling of fragments

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