Re: [IPsec] Avoiding Authentication Header (AH)

["Bhatia, Manav (Manav)" <[e-mail]>]

Hi Sean,

All I am saying is this:

There are many implementations that don't support AH as 4301 has a MAY support clause for AH.

Many people don't understand this. You could argue that its trivial and they should know this, but this aint an ideal world and people don't realize this.

Even within IETF there could be WGs looking at using or extending AH.

Given that ESP does everything useful that AH does, it makes no sense to continue using AH. I think we should have a draft that says this. However, there are some very corner cases where it *may* make sense to use AH (though I am still a little unconvinced, but I'll concede for the sake of moving on) and people are most welcome to do that.

If a WG ends up mandating AH (when ESP could have been used) then Yes it's a problem for everyone, right from the vendors to the users, who have to now support AH too in their products and networks.

And btw, what we're attempting here is not new in IETF. If you look at a very recent RFC 6472 which was published as a BCP then that's also very similar to what we're trying to do in the IPsec world. Folks had been using AS_SETs in BGP since a long time and its wasn't breaking down the networks. The BCP was published (to quote from the RFC) to:

   to simplify the design and implementation of BGP and to make the
   semantics of the originator of a route more clear.  This will also
   simplify the design, implementation, and deployment of ongoing work
   in the Secure Inter-Domain Routing Working Group.

Similar to the above RFC I think the draft in question does simplify a few things. There is work happening in KARP (that I know you're well aware of) where one of the requirements is to come out with a security mechanism that does NOT preclude the possibility of adding encryption services later. AH can never meet this requirement, so its practically out of the door. When we have so many documents hinting towards that (including the ones from NIST), then why are we being shy about admitting this openly.

I agree with Yaron that there is value in some document that recommends not using AH when ESP-NULL can be employed, and also that points out where AH does make sense.

Cheers, Manav 

-----Original Message-----
From: Sean Turner [mailto:[e-mail]] 
Sent: Thursday, January 05, 2012 9:01 AM
To: Bhatia, Manav (Manav)
Cc: [e-mail]; [e-mail]; Nico Williams
Subject: Re: [IPsec] Avoiding Authentication Header (AH)

Manav,

I'm trying to figure out whose implementation this situation will create a problem for?  If the new application or protocol ends up doing one of the 3 things you listed (http://www.ietf.org/mail-archive/web/ipsec/current/msg07401.html), then is the problem that those who haven't implemented AH now have to?

Are there any new applications or protocols that are mandating the use of AH?

Currently, I'm unconcerned about somebody sneaking a new protocol that mandates AH past the IETF because of this group.  This group certainly isn't made up of shrinking violets ;)

spt

On 1/4/12 9:22 AM, Bhatia, Manav (Manav) wrote:
> Hi Marc,
>
> We don't say that. 4301 says that implementations MAY support AH and MUST support ESP.
>
> This creates a problem for implementations if in future a new application or a protocol mandates the use of AH.
>
> I will even go a step further and say that newer protocols should just assume ESP-NULL and not even bother with AH if they can do with just ESP.
>
> Cheers, Manav
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, January 04, 2012 7:46 PM
> To: Bhatia, Manav (Manav)
> Cc: Nico Williams; [e-mail]
> Subject: Re: [IPsec] Avoiding Authentication Header (AH)
>
>
>>>>>> "Manav" == Manav Bhatia<Bhatia>  writes:
>      Manav>  Hi Nico,
>
>      >>  Advising (and updating said advice as circumstances change)
>      >>  use-IPsec protocol designers as to when to use ESP and/or AH is
>      >>  something we should do.  Deprecating AH seems like a nice idea,
>      >>  but if there's good reasons to still use it, then maybe not.
>
>      Manav>  We're not talking about deprecating or killing AH. I concede
>      Manav>  that I did allude to it in my first draft, but then changed
>      Manav>  the tone based on the WG feedback, to say that we should
>      Manav>  "avoid" AH wherever possible.
>
> This is the status quo already.
> Why do we need this draft?
>