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

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



Hello!

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

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

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

I think that before the draft be altered to include IPv4 source routing
headers (both loose and strict).  The replacement text should go in Appendix
A1, and it should closely resemble the text for the type 0 IPv6 routing
header.

And for those who think I'm rabblerousing, I have included the original note
from 1995 on this subject, which had no negative followups to it as far as I
could tell.  BTW, this is from the archives at ftp.ans.net, before IPsec
moved to its current home @tis.com.

Please note that the thinking at the time was based on deployed
implementations of routers.  I've looked at our code and BSD, and they both
do the predictable thing in their forwarding path.  I'd appreciate any
verification by major router vendors.

See you in LA!

Dan

===================== (Cut up to and including here.) =====================
Forwarded message:
>From ipsec-request@ans.net Thu Sep  7 16:21:19 1995
Message-Id: <199509071622.AA60862@interlock.ans.net>
From: Ran Atkinson <rja@bodhi.cs.nrl.navy.mil>
Date: Thu, 7 Sep 1995 12:21:19 -0400
Reply-To: rja@cs.nrl.navy.mil
X-Mailer: Z-Mail (3.2.1 10apr95)
To: ipsec@ans.net
Subject: possible AH & IPv4 compromise
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: rja@bodhi.cs.nrl.navy.mil


Folks,

  Bill Simpson was in town in late August and unexpectedly telephoned
me and then dropped by NRL 30 minutes later for a chat about
IPv4 options and AH.  This discussion largely consisted of Bill
"educating" me about things.

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

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

  This leaves only IPSO/BSO, IPSO/ESO, SATID, NOP and EOL as the
only really invariant options.  Of these, EOL and NOP don't impact
security.

  The software that Bill has mentioned that did reorder IPv4 options
is now ancient and has long been superceded by software releases that
do not reorder IPv4 options.  None of the major router vendors (by
market share) ever used the particular implementation that Bill cited.
I believe that implementations that reorder IP options are broken
(ignoring security, it is a PAINFUL performance hit) and should be
ignored in our mulling things over.

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

The compromise goes like this:

Included in AH computation:
	IP Version
	IP Header Length
	Total Length
	Ident
	Protocol
	Source Address
	Destination Address

	IPSO/BSO
	IPSO/ESO
	CIPSO  		(Option # available from Assigned Numbers,
			Option Length should be in the usual place)
	SATNET ID

Zeroed for AH computation:
	TOS		(enough real world routers munge this one
			that it ought to be excluded even though
			router munging of this sort really is evil)
	Frag Offset
	Flags Field
	TTL
	IP-layer Checksum

	All existing documented IP options other than
	IPSO/*, CIPSO, and SATNET ID


Ran
rja@cs.nrl.navy.mil

On behalf of Bill, Craig, and Ran...







Follow-Ups: