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

Re: AH Last Call complaint: No source route protection in IPv4!

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Dan" == Dan McDonald <danmcd@Eng.Sun.Com> writes:

    Dan> Hello!

    Dan> Mohan and I have were going over the latest batches on the IPsec
    Dan> mailing list about AH, and we realized that there is something
    Dan> missing from the current AH draft:

    Dan> IPv4 SOURCE ROUTING IS NOT PROTECTED BY AH IN ITS CURRENT REVISION.

    Dan> Thanks to Steve Bellovin for pointing out that it is not currently
    Dan> included in AH.  This is a big mistake (IMHO), because source routes
    Dan> in IPv4 _can_ be predicted with the same reliability that the type 0
    Dan> routing header in IPv6 can.

  It was originally protected in the RFC transforms. We realized a
snag when implementing it, which was brought up at the Detroit interop, and I
think later caused it to be removed again from the drafts.

    Dan> followups to it as far as I could tell.  BTW, this is from the
    Dan> archives at ftp.ans.net, before IPsec moved to its current home
    Dan> @tis.com.

  Thank you for the pointer. I am adding this to
http://www.sandelman.ottawa.on.ca/ipsec in MHonArc format.

    Dan> Please note that the thinking at the time was based on deployed
    Dan> implementations of routers.  I've looked at our code and BSD, and
    Dan> they both do the predictable thing in their forwarding path.  I'd
    Dan> appreciate any verification by major router vendors.
 
  My reading of BSD code says that Ran's note is correct. What is your notion?

    Ran> It turns out that the way one might read LSRR's specification is not
    Ran> the way it has been implemented in most systems that implement it.
*   Ran> It has been implemented so that the addresses recorded are NOT the
*   Ran> arriving interfaces of the listed intermediate systems but instead
*   Ran> the next-hop after leaving each listed intermediate system.  This
*   Ran> last isn't predictable in the general case.  I can see both
    Ran> interpretations in the text of RFC-791, but what matters is what has
    Ran> been implemented.

    Ran> Similarly, SSRR originally lists the inbound address of each
    Ran> intermediate hop but records the outbound address of each
    Ran> intermediate hop (at least in real world implementations).  Again,
    Ran> this makes SSRR unpredictable in the general case.  RFC-791 does
    Ran> appear to say this upon re-reading, but it is too subtly worded for
    Ran> my taste.

  ...

    Ran> Bill, Craig, and I think we have a compromise position on IPv4 AH
    Ran> processing.  At least one router vendor that Bill talks with has
    Ran> also agreed that this is reasonable.  I am altering the freely
    Ran> distributable NRL implementation to reflect this compromise.

  This suggests that we can now do AH over source routing?

   :!mcr!:            |  Sandelman Software Works Corporation, Ottawa, ON  
   Michael Richardson |Network and security consulting and contract programming
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>. 








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

iQB1AwUBNR00HtiXVu0RiA21AQFZLwMAjd3TU4FsvdO7560qLLz5ljJEeJrG0JJ/
3b35D1ENpmn7mgbpIunvCJM1prBE3Cvf/Fth6Df0hp+xy7AMsqA8ubKQijlRn+D0
QjTClYxCackMG5a9O+9FcNTMWRE+BnB+
=KAUq
-----END PGP SIGNATURE-----
References: