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

Re: Deprecation of AH header from the IPSEC tool kit


  {Michael, i've cut the CC list, since I'm not on isis-wg or rip, and my posts
don't go in anyway... you can put the CC back in and advise them the
rest of the conversation is on ipsec, I leave you on because I don't know
if you are on ipsec. Likely not, since we discussed this before.
  Feel free to forward my posts to isis-wg, etc....}

>>>>> "Michael" == Michael Thomas <mat@cisco.com> writes:
    Michael> That's true of v4 IP headers. Is it also true of v6 routing
    Michael> headers? Is it also true of all of the rest of the v6 headers? I
    Michael> appreciate Steve's argument on this, and I think they're valid
    Michael> -- for v4 IP headers.  What I don't agree with is that you can

  Thus my position:
	1) make AH a MAY for routers/gateways that want to support IPsec/IPv4.
		(I would prefer that end nodes SHOULD still support AH, but
		that affects fewer implementations (Sun, Free/SWAN, KAME,
		OpenBSD, Microsoft?), but more systems.. 

	Most people who are building gateways want privacy.

	2) *leave* AH as a SHOULD/MUST for IPv6, but in particular,
	leave the details of this (SHOULD/MUST) to the ipngwg to decide if
	they wish to have all end systems support it for future possible use
	by extension headers, or other stuff. 

  I say leave it to ipngwg to decide if IPsec AH is required (ESP is not
for political reasons. IPngWG may wish to change their mind on that point...)
because the decision whether or not to mandate AH in end systems is an
engineering question, not a security question.

  (Wow! Steve, stay off that reply key for a moment)

  Assume that Steve Bellovin has ocnvinced everyone that all current IPv6
extension headers to not benefit from AH, or carry information that could
be independantly verified from info stored in the SA-table. (e.g. legitimate
source addresses, pointers to PCBs). i.e. there is no current reason to
have AH vs ESP in IPv6. 

  The situation then becomes: if a new extension header is introduced that
would benefit (more precisely: be insecure and therefore undeployable) from
the protections that AH can provide, it then falls to the proponent of the
new extension to mandate that AH must exist. It may be hard to get agreement
that the extension is important enough to cause AH to be included in new
products, and the extension will never fly.

  The reason why we have a network layer WG, of course, is so that the
extension header, routing, etc. people don't have to invent the wheel over
and over again.
  So, it is really up to IPngwg to decide how much importance they want to
put on being able to do new IPv6 extension headers in a secure fashion.

    Michael> Hedge your bets by folding AH functionality into ESP (or
    Michael> something like ESP). This could be done by slavishly requiring
    Michael> AH functionality across the board, or it could be more clever
    Michael> and optimize only the cases where you have outer headers that
    Michael> need to be protected (and potentially which fields)

  I think that there is no advantage to folding AH functionality in ESP.
Numerous disadvantages in fact. 
  a) there is no code savings. If you have AH functionality, you have it,
	your ESP code path just has one more condition to test.

  b) the knowledge of whether or not you are doing AH functionality in
	ESP would not be carried in the packet, but rather in the SA, 
	since it would be negotiated. 

  c) an external observer can not distinguish ESP(NULL)+AH functionality
	from ESP(AES)+normal integrity. This is good if you are interested
	solely in traffic analysis. This is bad if you want to do auditing
	at security gateways (aka firewalls), etc.
	
    Michael> I'm not comfortable with #1 because smacks of being able to
    Michael> predict the future with too much certainty. #2 is certainly not
    Michael> easy since it would require a careful analysis of each header to
    Michael> determine whether there is any benefit to including it into the
    Michael> MAC calculation. However there would be a net reduction in
    Michael> complexity and header size if we nuked AH, so maybe it's worth
    Michael> it.

  There is no reduction in complexity if you create an ESP that covers
the headers. The question is more simply:
	rm rfc2402.txt

  or not.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:mcr@sandelman.ottawa.on.ca	mailto:mcr@solidum.com
Follow-Ups: References: