Subject: Re: [IPsec] Avoiding Authentication Header (AH)

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 09:34:21 -0500

Folks,

I mostly entirely agree with Michael Richardson's
analysis at the URL just below, namely that AH continues
to have utility -- but that utility is not VPN deployments.

Michael Richardson's note:
	<http://www.ietf.org/mail-archive/web/ipsec/current/msg07363.html>

HISTORY

Important history is that both ESP and AH were originally
products of the IPv6 Working Group.  They moved into the
IPsec WG because the IPsec WG had not made significant
progress at that time (early 1990s).

AH was created and exists primarily to enable authentication, 
including intermediate authentication, of IPv4 and IPv6 
options, extension headers, and so forth.  

BACKGROUND & AVAILABILITY:

Many modern silicon-based routers and firewalls, from multiple 
router vendors, can parse or parse-past options and optional 
headers at wire speed, so existence of an IP-layer option or 
extension does not today automatically push the IP packet 
on to what folks historically called the "slow path" for 
packet forwarding.  This makes it much more practical to
deploy IP options and IP optional headers now than in the
past.

Virtually all IPv6 hosts, and most IPv4 hosts, support AH 
in shipping product, and have done for ~15 years now.  This 
includes both commercial products and open-source implementations.  
Most major IPv6 routers, for example multiple product lines 
from both Cisco and Juniper, also support AH in shipping 
product and have done for some while now.  So AH remains 
a very widely available protocol.

CURRENTLY DEPLOYED USES:

While AH uses are limited today, just as the use of
IP options/extensions are limited today, current active 
uses of AH in real-world deployments today include at least
these -- built using commercial off-the-shelf products:

	- AH with IPv4 to authenticate sensitivity label 
	  options (e.g. FIPS-188, RFC-1108).

	- AH with IPv4 to prevent options-based attacks,
	  primarily in certain high-threat environments.

	- AH with IPv6 to authenticate certain IPv6
	  extension headers and options, primarily in
	  certain high-threat environments.

	- AH with IPv6 to prevent extension-header-based
	  and options-based attacks, primarily in certain
	  high-threat environments.

	- Many IPv6 deployments using OSPFv3 have enabled
	  OSPFv3 protection using AH.  Most router vendors,
	  including (for example) multiple product lines 
	  from both Cisco and Juniper, shipped this capability 
	  long ago -- and this use of AH is both interoperable 
	  and widespread, largely within IPv6 enterprise
	  deployments.  OSPFv3 itself is largely deployed in
	  enterprises today, as I/IS-IS is more popular with
	  ISPs.

	  [NOTE WELL:  AH for OSPFv3 has NOT been deprecated, and
	  remains on the IETF standards track.  It is interesting,
	  however, that author of this AH draft is trying to kill 
	  off the use of AH to protect routing information -- 
	  apparently because his employer does not offer this 
	  AH for OSPFv3 capability in its released products.]

	- Some IPv6 profiles, including the US Government
	  profile for IPv6, require AH support either generally
	  or in certain situations (example: to protect OSPFv3,
	  to authenticate certain IP options or IP extension
	  headers).

This WG ought not make existing legitimate uses of AH
invalid or not recommended.  There is no available alternative
for authenticating IP-layer options, extension headers,
and so forth.  AH is the only available way to do such
authentication at present.

FIREWALLS & MIDDLEBOXES:

While this WG has produced some documents with guidance
on how to approach parsing past an ESP header when NULL
encryption is used, we still do not have a completely
reliable way to parse past an ESP header when NULL 
encryption is used.  

By contrast, it is easy and quick to parse past an AH header 
-- either in the end system or in a firewall/router/middlebox.  
Several deployed firewall products in fact can and do 
parse past AH headers, either to perform deep packet inspection 
or simply to examine the transport protocol and port information.  

IETF PROCESS RULES:

Last, on an IETF Process note, the IPsec WG Charter posted
online is quite strict and is narrowly defined, with an
enumerated list of allowed work items.  To quote from
the charter:

	"The scope of the WG is restricted to the 
	work items listed above."

Neither changes to AH status nor Applicability Statements
for AH are listed in the WG Charter.

So it is not obvious that this document is within the charter 
for the IPsec ME WG.  

If the IPsec ME WG Chairs believe this work is within charter, 
they ought to post a note to the IPsec ME WG mailing list
citing the specific charter text authorising this topic.

IPsec ME Charter:
	<http://datatracker.ietf.org/wg/ipsecme/charter/>

A draft outside the Charter of an IETF WG ought not
be developed by or within that WG.  So I don't see 
how this document properly can be considered by this WG.

Yours,

Ran

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Jan 2012 06:43:33 -0800

> So it is not obvious that this document is within the charter 

It is obvious that it is not.

> If the IPsec ME WG Chairs believe this work is within charter, 

We do not. This mailing list is also used for anyone with drafts that deal with modern IPsec usage, such as the documents in this thread. Are you saying that such documents should not be discussed on this mailing list?

--Paul Hoffman

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 2 Jan 2012 20:46:10 +0530

[clipped]

> Most major IPv6 routers, for example multiple product lines from both Cisco 
> and Juniper, also support AH in shipping product and have done for some while now.  
> So AH remains a very widely available protocol.

It may be widely available, but clearly it isnt as widely used.

Are you suggesting that newer protocols should mandate AH or they should be proposing extensions to AH? I think all we're saying is that newer protocols should suggest extensions to ESP-NULL wherever possible. They must have a good reason to suggest mandating AH. What is the problem with this?

>	  enterprises today, as I/IS-IS is more popular with

The RFC that describes OSPFv3 authentication has the following line:

In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH.

You might also be interested in the following draft which will be published as RFC any time now:
http://tools.ietf.org/html/draft-ietf-ospf-auth-trailer-ospfv3-11

>	  AH for OSPFv3 capability in its released products.]

Really? I would like to try whatever you've been smoking.

>	  to authenticate certain IP options or IP extension

Just trying to understand. Is there a reason why ESP-NULL cant be used?

> This WG ought not make existing legitimate uses of AH invalid or not recommended.  

What makes you think that this draft is trying to do that?

> There is no available alternative for authenticating IP-layer options, extension headers, and so forth.  
> AH is the only available way to do such authentication at present.

If you include the ESP header before the extension headers can you not use it to authenticate the extension headers?

> FIREWALLS & MIDDLEBOXES:
>
> While this WG has produced some documents with guidance on how to approach parsing 
> past an ESP header when NULL encryption is used, we still do not have a completely 
> reliable way to parse past an ESP header when NULL encryption is used.  

And pray why is that?

Manav

---

From: Venkatesh Sriram <[email-masked]>
Date: Mon, 2 Jan 2012 21:13:36 +0530

If ESP and AH continue to co-exist then I see the following happening:
(i) standard for feature foo1 using ESP-NULL + SW effort + QA effort +
interop effort(ii) standard for feature foo1 using AH + SW effort + QA
effort + interop effort(iii) standard for feature foo2 using ESP-NULL
+ SW effort + QA effort + interop effort(iv) standard for feature foo2
using AH + SW effort + QA effort + interop effort..(iii) standard for
feature foo'n' using ESP-NULL + SW effort + QA effort + interop
effort(iv) standard for feature foo'n' using AH + SW effort + QA
effort + interop effort
Now, i am willing to live with this if the security offered by AH and
ESP-NULL is significantly different. I dont see why we should have
this complication if ESP-NULL can do everything that AH has to offer.
Why should the operators learn managing ESP and AH when both do the
same?
RFC 4301, by declaring ESP as a MUST and AH as a MAY has already set
the context. I dont see why vendors and everybody else in the food
chain should spend cycles on AH, if its not bringing anything
substantial on the table?
I dont think the draft in question says that AH is bad and should be
deprecated. It merely says that WGs should be circumspect when
mandating AH since its likely that most people are using ESP-NULL and
you dont want to unnecessarily add complexity in people's lives for no
good reason.
Sriram

---

From: Jack Kohn <[email-masked]>
Date: Tue, 3 Jan 2012 00:45:36 +0530

>          high-threat environments.

This piqued my interest.

Which "extension header" does AH specifically protect in these
"high-threat environments"?

In case of IPv4, which field in the IP header are you most interested
in protecting?

Jack

---

From: Jack Kohn <[email-masked]>
Date: Tue, 3 Jan 2012 00:54:42 +0530

> these -- built using commercial off-the-shelf products:

BTW, there is a discussion going on in NANOG on who uses AH and nobody
seems to be raising their hands.

Obviously, one cant take draw to much from that, but it just gives you
a data point.

Jack.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 16:11:08 -0500

> It may be widely available, but clearly it isnt as widely used.

Use of AH to protect OSPFv3 is not uncommon within
the set of sites that deploy OSPFv3.  It provides
protections that no other mechanism can provide,
for example it can be used to detect options-based
attacks.

> http://tools.ietf.org/html/draft-ietf-ospf-auth-trailer-ospfv3-11

I am well aware of it.  That document does NOT deprecate 
use of AH with OSPFv3 either.

> Just trying to understand. Is there a reason why ESP-NULL cant be used?

I gave a list earlier of a number of different scenarios where
and reasons why AH is used.  A subset of that list:
	- ESP null does not protect options/optional headers.
	- ESP null cannot reliably be parsed past.

> What makes you think that this draft is trying to do that?

The text in your two drafts on the topic.

> If you include the ESP header before the extension headers can you not use it to authenticate the extension headers?

That isn't possible, for various reasons.  

For IPv4, options always appear before the ESP header.

For IPv6, there are multiple reasons, including but not
limited to:
	- There still is no 100% reliable way to parse past an
	  ESP NULL header 
	-- IPv6 has strict rules on the order of headers
	   and an ESP NULL header can't appear before either 
	   a Routing Header or a Hop-by-Hop Options Header 
	   because those two header types need to be 100% readable 
	   by routers handling the IPv6 packet.

>> reliable way to parse past an ESP header when NULL encryption is used.  

The existing documents' methods aren't 100% reliable.
I wish they were, but they aren't.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 16:28:53 -0500

On 02  Jan 2012, at 14:24 , Jack Kohn wrote:
> BTW, there is a discussion going on in NANOG on who uses AH
> and nobody seems to be raising their hands.
> 
> Obviously, one cant take draw to much from that,
> but it just gives you a data point.

I absolutely believe that.  It is not a surprise.  
More data is almost always better than less data.

NANOG list membership is mostly, not entirely, but mostly, 
ISP folks and content providers.  Threat models for ISPs 
tend to focus on protecting the transit infrastructure 
and their provisioning/management platforms.  Many ISPs 
seem to share similar threat models.

Threat models for end users tend to be different -- and 
vary pretty widely.

I haven't been at an ISP for a decade, but I'd be surprised 
to see an ISP put a firewall in their transit network, 
whereas many enterprise deployments have multiple firewalls 
(and also IDSs and other boxes) throughout their network.

Threat models vary between ISPs and enterprises and other users.  
Common deployment models vary also by type of user.

ISPs tend to deploy I/IS-IS as their IGP for a range of reasons,
while other users more commonly deploy OSPF as their IGP.
No doubt there are exceptions to those trends.

Financial institutions are obvious examples of high-threat 
environments.  A compromise at a large financial institution 
could have a very high monetary cost to the victim institution.
Often this means large financial institutions find it 
worthwhile to deploy security measures that other sites 
do not find worthwhile.  

Cheers,

Ran

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 2 Jan 2012 13:53:35 -0800 (PST)

Hello,

> effort(iv) standard for feature foo'n' using AH + SW effort + QA

  If much of the above is not duplicative then you have bigger problems
that AH.

> this complication if ESP-NULL can do everything that AH has to offer.

  Ran has provided a good list of things that AH can do that ESP-NULL
cannot.

> substantial on the table?

  If it's a MAY then don't spend any cycles on it. Implementations that
support it MUST be prepared to interoperate with implementations that
do not.

> you dont want to unnecessarily add complexity in people's lives for no

  If you want to direct WGs to be circumspect when specifying AH then
why don't you go sit in those WGs and instruct them in what they should
be doing? Or at the very least comment during LC. Honestly, if a WG is
not paying attention to RFC 4301 then what makes you think they're gonna
pay attention to a random individual submission?

  I don't have any particular love for AH but this effort is really
lacking in one thing: a problem to solve. On the one hand, we're being
told that the effort is necessary because WGs developing a "standard for
protocol fool" need to be instructed on how to obtain integrity protection
but we're also being told that discouraging AH is OK because no one (in
NANOG) is using it and it's a MAY anyway. These seem to be somewhat
contradictory to me-- either no one's using it and we have a solution
in search of a problem; or, someone's using it and it would probably be
a problem to restrict its use in the future.

  I detect the strong arm of a weak product management department at
work here. If the engineers are complaining about implementing a protocol
that isn't being used then grow a backbone and tell your customers that
they're not gonna get support for a protocol they don't use.

  regards,

  Dan.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 16:58:01 -0500

On 02  Jan 2012, at 14:15 , Jack Kohn wrote:
> In case of IPv4, which field in the IP header
> are you most interested in protecting?

An IPv4 example would be validating the [FIPS-188]
IPv4 option, which can't be protected any other way.  

That option is supported by a range of operating systems,
both commercial and open-source.  I'm told by a
a major computer vendor that Linux supports this 
for both IPv4 and IPv6.  The option reportedly 
is deployed in environments ranging from certain 
large financial institutions to governments.
Some devices that perform IP routing also perform
security checks that ensure the label on a given
packet is in range for the output interface;
end systems also separately need to trust
the label integrity.

Similar IPv6 examples exist.

Yours,

Ran

---

From: Jack Kohn <[email-masked]>
Date: Tue, 3 Jan 2012 04:55:20 +0530

> Similar IPv6 examples exist.

And i would like to know what those are.

So you suggest that AH should be retained and encouraged since it
supports FIPS-188 IP option. Great.

What about IPv6? I am curious to know if you can come up with yet
another esoteric extension header or application that only a handful
of people know and have used - the way you have come up with IPv4.

Jack

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 18:55:04 -0500

On 02  Jan 2012, at 18:25 , Jack Kohn wrote:
> What about IPv6? 

As I noted, a range of examples exist for IPv6,
and another range of examples exist for IPv4.  

If one is inclined to study further, one possible 
starting place is the IANA registries of IP options 
and optional headers.  Most, but sadly not all, 
currently defined IPv4 and IPv6 options are listed 
by IANA in various registries:

	<http://www.iana.org>

Yours,

Ran

---

From: Jack Kohn <[email-masked]>
Date: Tue, 3 Jan 2012 05:45:34 +0530

We all know the different extension headers that exist in IPv6.

You said AH helps in securing IPv6 extension headers. I want to
understand which extension header did you specifically have in mind.

You cant protect fragmentation header, since fragmentation is done
after IPsec processing and the reassembly is done before IPsec
processing.

In case of Hop-by-Hop and Destination Options Header, its only the
Option Type and the Option Length thats included in the AH ICV
calculation. The data may or may not be included depending upon
whether it can be modified in transit or not.

ESP does not include the Option Type nad the Length.

So, whats the *real* operational risk that youre looking at?

AH covers the destination IP and the source IP. If somebody changes
them, IPsec processing will fail at the SPD checks. So what do you
gain by doing this?

Again, whats the *real* gain that we get by AH?

Jack

---

From: Jack Kohn <[email-masked]>
Date: Tue, 3 Jan 2012 05:51:48 +0530

And last but certainly not the least, why cant somebody use ESP-NULL
in the tunnel mode to protect the IP headers (including FIPS-188 IP
option that i have never seen anyone ever using).

Yours,

Jack

---

From: Nico Williams <[email-masked]>
Date: Mon, 2 Jan 2012 18:28:42 -0600

>        - ESP null does not protect options/optional headers.

ESP in tunnel mode is supposed to be the replacement for AH, and gets you this.

>        - ESP null cannot reliably be parsed past.

WESP is supposed to provide this.

Would tunnel mode be too expensive for new protocols that need
integrity protection of outer headers?

In any case, if there's no way to remove AH support from existing
implementations any time soon, then there's not much benefit to moving
AH to Historic either.  And it's clear that the controversy that has
arisen will take a fair bit of energy to resolve.  It may be best to
simply publish an Informational RFC providing advice on what new
protocols that say "use IPsec" should do.

Nico
--

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 3 Jan 2012 06:06:05 +0530

Hi Nico,

http://tools.ietf.org/html/draft-bhatia-ipsecme-avoiding-ah-00 is NOT trying to move AH to Historic.

Its merely trying to discourage newer applications and protocols from mandating AH as the same level of security can be achieved with ESP-NULL. The draft also says:

   It however, does not preclude the possibility of new
   work to IETF that will require or enhance AH.  It just means that the
   authors will have to explain why that solution is really needed and
   the reason why ESP with NULL encryption algorithm cannot be used
   instead.

I had initially published an Informational draft till a few folks pointed out that it could be a BCP.

Cheers, Manav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Tuesday, January 03, 2012 5:59 AM
To: RJ Atkinson
Cc: IPsec ME WG List
Subject: Re: [IPsec] Avoiding Authentication Header (AH)

On Mon, Jan 2, 2012 at 3:11 PM, RJ Atkinson <[email-masked]> wrote:
> I gave a list earlier of a number of different scenarios where and 
> reasons why AH is used.  A subset of that list:

Would tunnel mode be too expensive for new protocols that need integrity protection of outer headers?

In any case, if there's no way to remove AH support from existing implementations any time soon, then there's not much benefit to moving AH to Historic either.  And it's clear that the controversy that has arisen will take a fair bit of energy to resolve.  It may be best to simply publish an Informational RFC providing advice on what new protocols that say "use IPsec" should do.

Nico

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 19:45:49 -0500

> ESP in tunnel mode is supposed to be the replacement for AH,

Sadly, it cannot do so.  

Tunnel-mode isn't especially helpful here -- particularly 
for options or optional headers that are intended to be 
read/seen and their contents considered when forwarding 
transit IP packets.

In IPv4, ESP can't protect any IPv4 options, because the
ESP header always follows the IPv4 options.

In IPv6, there are also problems.  For example, if one has 
a Routing Header or Hop-by-Hop header then that would come 
BEFORE the ESP header -- precisely so that applicable routers 
or other middle boxes can see those headers in order to use 
their information during transit packet processing.  

> WESP is supposed to provide this.

Sadly, at present there is still no 100% reliable
method for parsing past an ESP header with NULL encryption.
There are various documents describing methods which
have various success probabilities, but none that is
100% reliable.

> integrity protection of outer headers?

As noted above, tunnel-mode would not solve the 
technical problem.

> protocols that say "use IPsec" should do.

We disagree on that.  Existing IPsec RFCs are clear enough.
If folks aren't going to read those, then they are not likely
to read any new Informational RFC either.  

Dan Harkins' analysis was spot-on, IMHO.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 19:47:50 -0500

> option that i have never seen anyone ever using).

As noted originally, those options need to be seen and
their contents considered by transit devices. 

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 19:51:11 -0500

On 02  Jan 2012, at 19:15 , Jack Kohn wrote:
> I want to understand which extension header did you
> specifically have in mind.

It isn't my job to write a document that isn't useful
or necessary.

I've supplied a subset of examples, which are sufficient
to illustrate that ESP with NULL encryption is not
equivalent to AH in the protection provided to IP
packets.

Yours,

Ran

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 3 Jan 2012 06:21:14 +0530

Ran,

> I am well aware of it.  That document does NOT deprecate use of AH with OSPFv3 either.

It doesn't need to because nobody uses it.

The reason the above draft exists is because there were many people (at least service providers) who said that they did NOT want to use IPsec for OSPFv3. I am sure you have customers who love using IPsec for OSPFv3, but there is a larger percentage that doesn't.

> The text in your two drafts on the topic.

You did not understand the drafts.

Please point to specific text that you think "make existing legitimate uses of AH invalid or not recommended."

The draft only talks about future applications and protocols.

[clipped]

> For IPv6, there are multiple reasons, including but not limited to:

Would appreciate if you can explain why you think WESP cannot reliably parse past an ESP header?

>	   by routers handling the IPv6 packet.

Routing Header is a security nightmare.

You were probably not aware that it has been recently deprecated by the IETF.

http://tools.ietf.org/html/rfc5095

>From the draft-bhatia-ipsecme-avoiding-ah-00:

   Hop-by-Hop options are not an issue, as the intermediate
   hops do not have keys to verify the message authentication code so
   they cannot really be protected anyways.

If you think not having ESP header before a few headers is a concern then we should fix that. If fixing this thing can get us rid of one protocol then its probably a good thing to do.

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 3 Jan 2012 06:24:00 +0530

And most of these are considered dangerous and are generally discouraged.

http://tools.ietf.org/html/rfc6398

Cheers, Manav 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of RJ Atkinson
Sent: Tuesday, January 03, 2012 6:18 AM
To: IPsec ME WG List
Subject: Re: [IPsec] Avoiding Authentication Header (AH)

> option that i have never seen anyone ever using).

As noted originally, those options need to be seen and their contents considered by transit devices. 

Ran

---

From: Nico Williams <[email-masked]>
Date: Mon, 2 Jan 2012 19:06:18 -0600

> read/seen and their contents considered when forwarding

With tunnel mode you effectively repeat the options inside and outside
the tunnel.  Routers can't validate the integrity protection
regardless of whether AH or ESP-NULL in tunnel mode is used, but
assuming that an attacker can only modify options at one place in the
path then the recipient can see that options were modified.

This is applies to both, IPv4 and v6.

> have various success probabilities, but none that is

Sure, this is necessarily true until any replacement for AH is
universally deployed and that indicates that only integrity protection
is provided.

Nico
--

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 20:22:01 -0500

> It doesn't need to because nobody uses it.

I know of multiple sites who have it deployed today.

> The reason the above draft exists is because there were
> many people (at least service providers) who said that
> they did NOT want to use IPsec for OSPFv3.

More precisely, a few service providers and a few vendors 
said this.  Major vendors had already shipped the capability,
and numerous users had deployed it.  

Unfortunately, the IETF has long-standing challenges with 
getting users/operators, especially enterprise/academic/
government users, to participate in its WGs.

Service providers are overwhelmingly using IS-IS for IPv6, 
not OSPFv3, in any event.

> I am sure you have customers who love using IPsec for OSPFv3,
> but there is a larger percentage that doesn't.

One of my clients operates a multi-continent IP network.
I also have non-ISP clients.  You acknowledge that you 
have no contact with the IPsec for OSPFv3 users.
So, by your own admission, I have more data than you do.

We disagree on the percentages.

> http://tools.ietf.org/html/rfc5095

Actually, the IPv6 Routing Header itself is not deprecated.
Only the RH Type 0 was deprecated by RFC-5095.

IANA.org reports the Type 2 and Type 3 IPv6 Routing 
Headers remain valid and are not deprecated (Type 3 
is work in progress, but allocated already).

>   hops do not have keys to verify the message authentication
>   code so they cannot really be protected anyways.

That claim isn't true either.  

Please consider deployments where the intermediate hops 
DO have those keys, obtained for example from a KDC.  
The IETF has standardised Kerberos, for example, so
a standards-based solution exists in this area.

Separately, RFC-4359 specifies how one can use 
RSA/SHA-1 signatures within AH.  So it is entirely
possible to give a middle box a verification key --
without also giving the middle box a signing key
for the traffic being protected.

I'm not going to write the I-D for you, nor am I going
to waste my time enumerating every single problem
with the draft.  There are too many technical flaws
and it would take too long.  I can't improve upon 
Dan Harkins' explanation of why trying to fix the 
I-D is a waste of time and energy.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 20:26:52 -0500

> http://tools.ietf.org/html/rfc6398

That RFC says the Router Alert Option might be abused
by malicious transit traffic in global public transit 
networks, depending in part upon the quality of one's
router implementation(s).

It also says that the Router Alert Option can be deployed
safely, for example within an Administrative Domain
or in an Overlay deployment.

It does not say that all hop-by-hop options are always bad.
In fact, it says that they are often useful and can be
deployed safely.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 2 Jan 2012 20:34:45 -0500

On 02  Jan 2012, at 20:06 , Nico Williams wrote:
> the tunnel.  

One could repeat the headers; some implementations don't.  
It doesn't help transit devices to repeat the headers
if they can't validate them before acting upon them.

> Routers can't validate the integrity protection
> regardless of whether AH or ESP-NULL in tunnel mode is used,

Disagree.  Intermediate authentication can be performed
by routers/firewalls, at least when AH is used.  The
router/firewall could then act on the options in the
packet having reasonable assurance that the option itself,
and its contents, were valid for that packet.

> but assuming that an attacker can only modify options at one place in the

Unfortunately, it is not really a generally valid assumption
that there is only 1 potential attack point along a path.

> universally deployed and that indicates that only integrity
> protection is provided.

If some such mechanism exists, and if it provides 100% reliable
ability to parse-past/parse-into, and if it is plausibly efficient 
to parse-into/parse-past in real-time for high-performance 
switches/routers/firewalls, then this discussion might be 
more useful than it is at present.  That is rather a lot
of IFs, however, none of which seem true today.

Yours,

Ran

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Jan 2012 23:08:49 -0500

>>>>> "Jack" == Jack Kohn <[email-masked]> writes:
    Jack> We all know the different extension headers that exist in
    Jack> IPv6.

    Jack> You said AH helps in securing IPv6 extension headers. I want
    Jack> to understand which extension header did you specifically have
    Jack> in mind.

let me ask a different question:  what's the savings in obsoleting AH,
given that RFC4301 already makes it optional, and many vendors have
already implemented, tested and deployed the code?

    Jack> So, whats the *real* operational risk that youre looking at?

    Jack> AH covers the destination IP and the source IP. If somebody
    Jack> changes them, IPsec processing will fail at the SPD checks. So
    Jack> what do you gain by doing this?

    Jack> Again, whats the *real* gain that we get by AH?

AH works for multicast, and could work even when the receiver does not have
the key.  

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Jan 2012 23:09:11 -0500

>>>>> "Jack" == Jack Kohn <[email-masked]> writes:
    Jack> And last but certainly not the least, why cant somebody use
    Jack> ESP-NULL in the tunnel mode to protect the IP headers
    Jack> (including FIPS-188 IP option that i have never seen anyone
    Jack> ever using).

Someone can.
Nothing stopping anyone.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Jan 2012 23:14:44 -0500

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:
    >> Routers can't validate the integrity protection regardless of
    >> whether AH or ESP-NULL in tunnel mode is used,

    RJ> Disagree.  Intermediate authentication can be performed by
    RJ> routers/firewalls, at least when AH is used.  The
    RJ> router/firewall could then act on the options in the packet
    RJ> having reasonable assurance that the option itself, and its
    RJ> contents, were valid for that packet.

Just to add to this: this intermediate authentiation requires a
different key distribution protocol than most VPN vendors are used to.

In certain kinds of deployments, manually keyed AH and ESP is actually
not that unusual (to many intermediate nodes too), and it makes sense
for the small amount of traffic that is anticipated.  

Ran, as you've been rather inactive in IPsec, I suspect that some people
might not know what pieces of code and specification you wrote, and who
paid you to write those pieces of code.

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 Jan 2012 17:41:47 -0600

> and its contents, were valid for that packet.

OK, so you have networks using manually keyed SAs with
routers/firewalls sharing the same SAs.  I hadn't considered that as
it isn't exactly scalable.  But fair enough.

> that there is only 1 potential attack point along a path.

I elided the point that an attacker who can modify the packets close
to the sender and recipient could hide any in-flight changes from the
recipient.  But if there are middle-boxes with access to the SAs' keys
then that doesn't apply.

> of IFs, however, none of which seem true today.

Fair enough.

Nico
--

---

From: Jack Kohn <[email-masked]>
Date: Wed, 4 Jan 2012 08:32:51 +0530

> government users, to participate in its WGs.

The problem is not this.

The problem is that a few loud people (in some occasions, just one)
can filibuster good ideas over long held antiquated views on how
technology is (or should be) used. In a few cases, its got little to
do with the technology really ..

Yours,

Jack

---

From: Nico Williams <[email-masked]>
Date: Tue, 3 Jan 2012 23:49:06 -0600

> do with the technology really ..

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.

In 2012 the use of manually keyed unicast SAs with group shared keys
is not exactly impressive (because not scalable).  We could reach
consensus to ignore such usage of IPsec.  Or not -- hardly a big deal
if not, eh?

Nico
--

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 4 Jan 2012 11:35:52 +0530

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.

We're not talking about deprecating or killing AH. I concede that I did allude to it in my first draft, but then changed the tone based on the WG feedback, to say that we should "avoid" AH wherever possible.

What we're trying to say is this:

1. If folks have a reason to use AH then they're most welcome to use it. 

2. If there are topologies where it makes only sense to use AH then do that. Ran pointed out to some very specific cases where it apparently makes sense to use AH and I have no problems with people using AH there. In the view of most people there isn't a need for AH in the service provider network and I am fine with a few people disagreeing with me. 

3. If there are newer protocols that cant use ESP-NULL for some reason and need to extend AH, then they should do that. All we're saying is that those folks should not arbitrarily extend AH. They should have a good reason for doing so.

In short, if ESP-NULL can do the job, then DON'T mandate AH - no point having multiple protocols doing the same stuff. If it cant, then either (i) fix ESP or (ii) go ahead and use AH. Pick up whichever is more elegant and preferred by the community.

I think that's all that we're trying to say here.

Cheers, Manav

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 4 Jan 2012 06:39:43 -0500

On 04  Jan 2012, at 00:49 , Nico Williams wrote:
> use-IPsec protocol designers as to when to use ESP and/or
> AH is something we should do.  

This has already been done.  More than once.
For a start, the latest IPsec RFCs contain advice.  
There are also other RFCs with such advice, 
including a relatively recent BCP on use of IPsec.  

There is no evidence of any recent change either 
to the operational circumstances or to the available 
alternatives.  So no update is appropriate at this time.

> Deprecating AH seems like a nice idea, but if there's good

There are deployments now and have been deployments 
all along -- and those deployments don't have any
alternatives to AH.

> In 2012 the use of manually keyed unicast SAs with
> group shared keys is not exactly impressive (because not scalable).  

Actually, that assumption is not valid.  There are 
multiple approaches to scalability available now.  

An obvious example is to use a KDC to distribute keys.  
Another example is to use existing provisioning systems 
to provision keys.  ISPs have a wide range of provisioning 
systems, often locally developed.  Enterprise users vary 
-- larger enterprises often have provisioning systems; 
smaller enterprise users less often (although their scale 
is also smaller).  Many enterprise equipment vendors 
offer centralised management platforms that include
provisioning capability, often multi-vendor provisioning
capability.  There is also a standards-based approach
to configuration/provisioning -- using NetConf.  There
are even approaches that use RADIUS to distribute wrapped
keys.  

Yours,

Ran

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Jan 2012 09:16:02 -0500

>>>>> "Manav" == Manav Bhatia <Bhatia> writes:
    Manav> Hi Nico,
 
    >> 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?

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 4 Jan 2012 19:48:10 +0530

> There is no evidence of any recent change either to the operational 
> circumstances or to the available alternatives.  So no update is appropriate at this time.

One major recent change is the publication of WESP [RFC 5840] and the standard for using Heuristics for detecting ESP-NULL packets [RFC 5879]. 

This takes away one major reason why folks wanted to use AH - that of being able to deep inspect packets.

Even the NIST guidelines for IPv6 deployment says that the main argument in favor of AH is the ability to inspect packets. With WESP even that goes away.

BTW, the Advanced Network Technologies Division of NIST has started work on supporting the WESP header and ESP-NULL detection.
http://dns.antd.nist.gov/ipv6/

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 4 Jan 2012 19:52:12 +0530

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: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 04, 2012 7:46 PM
To: Bhatia, Manav (Manav)
Cc: Nico Williams; [email-masked]
Subject: Re: [IPsec] Avoiding Authentication Header (AH)

    Manav> Hi Nico,

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 4 Jan 2012 13:37:19 -0500

On 04  Jan 2012, at 09:18 , Bhatia, Manav (Manav) wrote:
> One major recent change is the publication of WESP [RFC 5840]
> and the standard for using Heuristics for detecting ESP-NULL packets
> [RFC 5879]. 
> 
> This takes away one major reason why folks wanted to use AH -
> that of being able to deep inspect packets.

Unfortunately, that is wishful thinking, rather than reality.

Neither WESP nor the other document provide a 100% reliable way 
to parse-into/parse-past/deep-inspect ESP packets.  One might 
wish otherwise, but the reality is that there is no 100%
reliable method today.

Separately, as I've noted before, that isn't the only reason
that folks use AH today in real-world deployments.
 
> Even the NIST guidelines for IPv6 deployment says that the main argument in favor of AH is the ability to inspect packets. With WESP even that goes away.

Since WESP is not 100% reliable, WESP does not affect
that reason to retain AH.

Yours,

Ran

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Jan 2012 10:46:35 -0800

> wish otherwise, but the reality is that there is no 100%

<Chair-hat = on>
Can you give an example where WESP (a protocol that was done in this WG) is not 100% reliable for parse-into or parse-past? If we need to change the protocol, we should.

--Paul Hoffman

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 4 Jan 2012 13:59:11 -0500

On 04  Jan 2012, at 13:46 , Paul Hoffman wrote:

> Can you give an example where WESP (a protocol that was
> done in this WG) is not 100% reliable for parse-into
> or parse-past? If we need to change the protocol, we should.

Such packets have been encountered by prototype 
implementations in at least one firewall.  I will
certainly encourage those folks to share a sample
packet here, but they don't usually show up at IETF
and can be very shy.

I think WESP was a valiant try, and it seems to work
most of the time.  It is just sad that the result 
just doesn't work in all cases.  

An entirely separate issue is that WESP is not generally
available yet.  One hopes that WESP support will become
available soon, but that's not generally true now.

Yours,

Ran

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Jan 2012 11:27:30 -0800

> packet here, but they don't usually show up at IETF

Really? That's it?

> just doesn't work in all cases.  

You still haven't justified that statement, at least in my mind. I welcome any of the shy people to speak up, even through a proxy such as Ran.

> available soon, but that's not generally true now.

That is not an issue for this thread.

--Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 04 Jan 2012 21:58:51 +0200

Hi Ran,

I find the situation quite amusing, with fleeting little packets, timid 
engineers, and valiant standards people playing in this drama.

But seriously, could it be that you're confusing the (AFAIK) fully 
deterministic WESP (RFC 5840) with the non-deterministic heuristic 
method (RFC 5879)? Or else is there anything missing in WESP that we 
should pay attention to, for example, maybe it doesn't support specific 
IV or ICV sizes that those non IETF-goers are using?

Thanks,
Yaron

---

From: Nico Williams <[email-masked]>
Date: Wed, 4 Jan 2012 14:13:28 -0600

> An obvious example is to use a KDC to distribute keys.

Out of curiosity, does such a protocol for keying SAs at end-points
and sharing the keys with routers/firewalls exist, and is it
implemented in any routers/firewalls?

Also, whether using an out-of-band provisioning system or a KDC, you
still have the problem that you need O(N^2) SAs to be pre-keyed (or,
if keyed dynamically, the middle-boxes need to be able to go fetch
keys dynamically unless they are the KDCs).  I can imagine a system
with static-static DH key exchange, with trusted middle-boxes knowing
the private DH keys.  A system with symmetric keying only would be
severely limited by the O(N^2) SA keying requirement, and would be
limited in applicability to VPN (including BITW) applications and
small end-to-end applications.

Nico
--

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 5 Jan 2012 04:11:18 +0530

Ran, 

> Such packets have been encountered by prototype implementations in at least one firewall.  
> I will certainly encourage those folks to share a sample packet here, but they don't 
> usually show up at IETF and can be very shy.
>
> I think WESP was a valiant try, and it seems to work most of the time.  
> It is just sad that the result just doesn't work in all cases.  

As a co-author of WESP I can tell you that the design was whetted by several HW teams and it works *all* the time. The design was reviewed and approved by major silicon vendors and fortunately for you I am not speaking for a few shy people who refuse to be recognized, but some very audacious people who have sent their approval mails on this mailing list and have stood up and spoken in favor of the WESP design - multiple times.

The NIST Guidelines for Secure IPv6 deployment also refers to WESP as a protocol that can be used to disambiguate ESP-NULL from encrypted ESP packets. A SW division of NIST has already started working on supporting WESP.

Given this I would appreciate if you can stop your rant against WESP till you come up with a real technical reason of why you think WESP is unreliable and "just doesn't work in all cases".

Cheers, Manav

---

From: Jack Kohn <[email-masked]>
Date: Thu, 5 Jan 2012 05:26:25 +0530

> IV or ICV sizes that those non IETF-goers are using?

This stumped me for some time and i went back to read RFC 5840.

The HdrLen in the WESP header will always point to the start of the
unencrypted payload for the devices to inspect. No matter what IV or
ICV size folks use, WESP will always work (contrary to claims made by
a few individuals on the list).

Jack

---

From: Sean Turner <[email-masked]>
Date: Wed, 04 Jan 2012 22:31:06 -0500

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:
>>>>>> "Manav" == Manav Bhatia<Bhatia>  writes:
>      Manav>  Hi Nico,
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 05 Jan 2012 08:35:15 +0200

I agree.

     Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 05 Jan 2012 09:22:43 +0200

Hi Sean,

first, thanks for the collective compliment. But in fact I have seen two 
recent cases where IPsec/IKE-related work did manage to sneak past this 
workgroup until quite late in the process ( 
http://tools.ietf.org/html/draft-ietf-hokey-rfc5296bis-06, 
http://tools.ietf.org/html/draft-ietf-dime-ikev2-psk-diameter-11). It 
may be a matter of lack of communication or lack of energy, but these 
things do happen. So I do see value in a draft that explicitly 
recommends not using AH in general, and points out where AH does make sense.

Thanks,
Yaron

On 01/05/2012 05:31 AM, Sean Turner wrote:
> 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?
>
>> 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
>>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 5 Jan 2012 15:13:08 +0530

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:[email-masked]] 
Sent: Thursday, January 05, 2012 9:01 AM
To: Bhatia, Manav (Manav)
Cc: [email-masked]; [email-masked]; 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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Jan 2012 16:00:36 +0200

Bhatia, Manav (Manav) writes:
> One major recent change is the publication of WESP [RFC 5840] and
> the standard for using Heuristics for detecting ESP-NULL packets
> [RFC 5879].  
> 
> Even the NIST guidelines for IPv6 deployment says that the main
> argument in favor of AH is the ability to inspect packets. With WESP
> even that goes away. 

Getting WESP implemented to the boxes will require a lot of time.
There are still lots of boxes which do not even support IKEv2 (which
is required for WESP) and IKEv2 has been out for 6 years already. AH
might already be implemented on some boxes, so using it might offer
faster deployment time than WESP. The only *protocol* benefit WESP
have over AH is that it works through NATs.

As I see it the main reason AH is now MAY, not MUST, is that there has
not been that much use for it, and that has caused it to be as second
class citizen in the VPN driven IPsec work. Because of that testing
etc has been somewhat ommitted. For example most of the
interoperability events has concentrated ESP testing, and only very
briefly done some AH testing (if there has been extra time).

Because quite a lot of IPsec development have been driven by the VPN
vendors, who do not have use for AH (or WESP), those vendors have seen
the previous mandatory to implment AH, as unnecessary burden for their
implementations. Thats why degrading it to MAY was good way forward in
the RFC4301.

This does not mean there is no use for AH in some environments. I
personally (at least now) think that it would have been more useful to
just say use AH than to create WESP (and heuristics) at all... That
would have given some use cases for AH, which would have then perhaps
moved it back to used track in the IPsec protocol family.

I myself think there is no reason to say anything about AH at this
point. It is MAY, so nobody needs to implement it. Every new protocol
using IPsec should consider whether they want to use ESP, ESP-NULL,
WESP, or AH and make their own decisions based on what would be best
for that environment and protocol. I.e if you require confidentiality
then you needs to use ESP, if you require transport mode outer IP
option protection you need to use AH, otherwise you can pick any of
them...

If you want to make sure other protocols do not unnecessarely specify
AH for their use, you should just participate in writing those
specifications and explain why do you think AH should be avoided in
that environment. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Jan 2012 16:23:06 +0200

> MAY support clause for AH.

Just noting that same is true for WESP. It is not mandatory to
implement, and I would claim there are way more implementations out
there supporting AH than there are supporting WESP. 

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

If there are some, just point us to them... anyways extending AH would
clearly require comments from the IPsec community so doing such thing
and not getting comments from this list would (or at least should) be
impossible.

> 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.

ESP-NULL does not provide the "reliable 100% proof" ability to parse
past the header. WESP does, but that is in the same category in the
implementations than AH (MAY), so that does not help.

Heuristics does provide a way to parse past the headers, but people
claim it is not reliable enough for them, and again it is in same
category in the implementations. Altough deploying heuristics
implementation is faster as it only requires changes to middleboxes
not end nodes...

> 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.

If WG wants to mandate AH, and we cannot convince them otherwise,
having a document which says so does not help. On the other hand if we
have stealth WG trying to sneak AH past IPsec community, I think they
will also conviently ignore this document too.

In summary I do not think there is problem, and I do not think we need
to say anything about AH right now.
-- 
[email-masked]

---

From: Markku Savela <[email-masked]>
Date: Thu, 05 Jan 2012 16:26:03 +0200

I don't understand why this discussion is needed.

AH is end-to-end, and the transformations to be used
for the connection are negotiated with key negotiation
and configured policies.

If end points don't want to use AH for whatever
reason (like not implemented), they are not asking it.

If end points decide to us it, they have it implemented,
it is their business and it should be irrelevant for any
intermediate node (for deep onboxious packet inspection,
skipping AH is trivial matter).

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 5 Jan 2012 20:07:07 +0530

> There are still lots of boxes which do not even support IKEv2 (which is required for 
> WESP) and IKEv2 has been out for 6 years already. AH might already be 

WESP can be used with manual keying the way routing protocols today use ESP and AH.

Manav

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Jan 2012 17:02:52 +0200

Bhatia, Manav (Manav) writes:
> > There are still lots of boxes which do not even support IKEv2
> > (which is required for WESP) and IKEv2 has been out for 6 years
> > already. AH might already be
> 

Hmm... RFC5840 says:

----------------------------------------------------------------------
2.3.  IKE Considerations

   This document assumes that WESP negotiation is performed using IKEv2.
...
----------------------------------------------------------------------

It seems the RFC5840 assumes you use IKEv2, but there might be some
other document to specify manual keying for WESP. Or it could be said
that RFC4301 section 4.5.1 covers also WESP... Actually I think it
will.

Anyways do you really think manually keyed WESP is feasible method to
be used in large enterprises requiring deep packet inspection just so
they do not need to replace obsoleted IKEv1 protocol with much better
and actually working IKEv2?

And why would routing protocols need to use WESP, I would assume they
use ESP-NULL instead. In addition if you use manual keying you can
also use mandated by policy "100% reliable" heuristics method from
RFC5879 section 2.2.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Jan 2012 17:47:30 +0200

> WESP can be used with manual keying the way routing protocols today use ESP and AH.

Hi Manav.

I guess it can, but ESP (and AH and presumably WESP) would be implemented at a lower layer than IKE. For some boxes that would be ESP implemented in silicon and IKE implemented in software.

So getting your own box to start doing IKEv2 is relatively straightforward - a software fix (even if it's referred to as "firmware"), while WESP would require a new box. Even in software implementations the IPsec is usually considered more "stable" than the IKE code.

The big vendors have taken years to implement IKEv2 in regular boxes (as opposed to lab curiosities). I don't see them rushing to implement WESP just to please the middlebox makers.

Yoav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 5 Jan 2012 21:34:09 +0530

Hi Yoav,

I see some potential of using WESP in the routing protocols where it helps the end nodes in prioritizing certain control packets over the others. 

One could argue that the end nodes know that the packets are NULL encrypted and could use regular ESP as well. The problem with this is that the end nodes then need to install per SPI filter entries which is not scalable. Packets need to be punted to separate queues since Ipsec processing is often done in SW after the packets have been dequeued from the CPU queues.

This is not a completely sorted idea and I need to spend more time on this to see if it makes sense ..

Cheers, Manav

P.S.
BTW, one vendor recommends AH for OSPFv3 (despite 4522 stating that as a MAY) since it helps their implementation to prioritize OSPFv3 packets.

-----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Thursday, January 05, 2012 9:18 PM
To: Bhatia, Manav (Manav)
Cc: Tero Kivinen; IPsec ME WG List
Subject: Re: [IPsec] Avoiding Authentication Header (AH)

On Jan 5, 2012, at 4:37 PM, Bhatia, Manav (Manav) wrote:

>> is required for

Hi Manav.

Yoav

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Jan 2012 08:22:54 -0800 (PST)

> Bhatia, Manav (Manav) writes:
[snip]
> to say anything about AH right now.

  Indeed! I agree 100%. Me too. +1. Etc.

  Dan.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 11 Jan 2012 20:25:47 +0530

Hi Tero,

[clipped]

> And why would routing protocols need to use WESP, I would assume 
> they use ESP-NULL instead. In addition if you use manual keying 

Sigh. We've gone through this before I think on the KARP mailing list (am not sure though).

Routing protocols could "potentially" use WESP since they need to prioritize certain control protocols over the other protocol packets (like OSPF hellos and acks over other OSPF packets). Using WESP just makes deep inspection easy. One could argue that routers know that incoming ESP-NULL packets are not "encrypted" since they are the end points, however, that means that routers need to install filter rules per SPI values, which is not scalable. So, while ESP-NULL *would* work, WESP just makes it a tad easier.

Cheers, Manav

---

From: "Panos Kampanakis" <[email-masked]>
Date: Fri, 13 Jan 2012 17:57:16 -0500

Agreed. Summarizes my opinion too.

Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dan Harkins
Sent: Thursday, January 05, 2012 11:23 AM
To: Tero Kivinen
Cc: [email-masked]; Bhatia,Manav (Manav)
Subject: Re: [IPsec] Avoiding Authentication Header (AH)

[snip]

  Dan.