Hi Enno and list,

Enno Rey <[email protected]> writes:

> hope everybody had a great #RIPE70 meeting. We did!
> Many thanks to the organizers and chairs!

and thanks to the actual speakers as well the speakers we had to turn
down due to time constraints, too:-)

> If the chairs consider this appropriate we will happily give a
> presentation on this stuff in Bucharest or at another occasion.

Sounds good to me!

> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to
> their number, order[...]

Actually, as far as I'm concerned that's the real core of the problem.
Or more specifically, the first two lines of RFC 2460, section 4.1:

   When more than one extension header is used in the same packet, it is
   recommended that those headers appear in the following order:

followed on the next page by

   Each extension header should occur at most once, except for the
   Destination Options header which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

Note in particular that these are not even RFC 2119 "SHOULD" or
"RECOMMENDED" and such.

The impact here is actually at least twofold: 

- It is impossible to implement this as a simple pipeline architecture
  in hardware; at least for cases deviating from the "recommendations"
  above this effectively becomes either excessively complex to implement
  in hardware or an invitation to DoS when implemented in software on an
  otherwise hardware router.

- As I understand it, at least some of the issues you have found are
  effectively based on violating the second paragraph quoted, making it
  impossible to come up with a lower bound on how long the header chain
  can actually get and therefore leading to the fragmentation related
  attacks and similar you have discovered.

The original idea was that the extension headers are processed strictly
in the order they occur, so one question to ask is if there is any valid
reason to violate these "recommendations" for other than malicious
purposes.


Cheers,

    Benedikt

-- 
Benedikt Stockebrand,                   Stepladder IT Training+Consulting
Dipl.-Inform.                           http://www.stepladder-it.com/

          Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/

Reply via email to