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

Re: Part Two: IPv4 Options We Can't Handle



In message <9508232111.AA19555@flagstaff.Princeton.EDU>, "David A. Wagner" writ
es:
>You forgot a few:
>
>	3. modularity: the AH transform should be a modular protocol.

	Not so. IPsec reaches its tentacles into a lot of places in any
layering model I've seen (in BSD, for instance, we're talking sockets,
transport, and network layers). Modularity is a good design ideal, but it's
not clear to me that the kind of security guarantees IPsec would like to make
can be done without violating layering.

>	4. functionality: the current AH spec precludes IP ESP AH .. packets.
>		(Do you see why?)

	You can't put optional headers inside an ESP payload without another
IP header (giving you tunnel mode). While we can get along without this rule,
it ends up making implementations much less complex on the output side. The
two valid packets similar to what you have there are IP AH ESP [ULP] and
IP ESP [IP AH ULP].

>I think we have here a fundamental disagreement about what data
>AH should guarantee the authenticity of.

	Agreed, as I have said in previous messages.

>We agree that AH must guarantee the authenticity of the payload
>and the AH header.  But we disagree beyond that: I claim that AH
>should not (and need not) guarantee the authenticity of the IP
>options, at least for IPv4.  (More precisely, if a SA demands
>authenticity of certain IP options, I believe that the implementation
>should encapsulate first, saving those IP options, and then apply
>AH to the resulting datagram.)
>
>I haven't seen any attack on my view of what AH should authenticate,
>and I haven't seen any attack on your view.  I think they're probably
>both secure.  So the argument is over issues of modularity, cleanness,
>expandability, and functionality -- not over security!

	There are thousands of real users of IPSO right now who would not
agree with your statement that IPv4 options need not be protected. The same
security-conscious sites that use IPSO and CIPSO right now are a significant
portion of IPsec's potential user base. Failing to deliver on what could be
their main requirement for IPsec will NOT make them happy, will NOT cause them
to buy into IPsec, and will NOT help IPsec's deployment.

	To me, IPSO/CIPSO is a harsh market reality that IPsec must face.
The good news here is that, because they are invariant [or BETTER BE ;)],
protecting them with AH is tractable.

									-Craig


Follow-Ups: