Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

[RJ Atkinson]

On 02  Apr 2014, at 16:17 , Paul Hoffman wrote:
> Actually, yes. Looking in the archives,
> I see you stating it in a few different threads.

Again, that's not what I said, but instead 
what you have mis-read.

>> A general IPsec Requirements document ought to be addressing
>> all deployed use cases, and ought not be limited to VPN uses.
> 
> If that's what the WG wants, great. In me reading the
> list as a document author, I don't see people agreeing with that.

If this I-D is NOT addressing all IPsec use cases, then why isn't
this I-D titled the "IPsec VPN Requirements" document ?

> Good catch. Proposed improvement:
> 
>   The IPsec community generally prefers ESP with NULL encryption over AH.
>   AH is still required in some protocols and operational environments when
>   there are security-sensitive options in the IP header, such as source
>   routing headers; ESP inherently cannot those IP options.

I assume you meant to write:  s/cannot those/cannot protect those/

If I understand the intended text, that is an important and very helpful 
improvement, and I very much appreciate it being added.

>> It also should mention IP sensitivity label options, such as RFC-1108 
>> and RFC-5570 as a use case for AH, in addition to source-routing headers.
> 
> Having this document listing all of the IP options from Informational RFCs
> would undermine the value of this document.

  Adding s/source routing headers;/source routing headers or sensitivity
label options;/  plus adding those 2 RFC citations to your "proposed 
improvement" text above could not possibly "undermine the value of this 
document", particularly since both RFCs are examples of currently
deployed use cases.

  Please re-consider applying the brief text edits I've provided just above 
and the corresponding citations to those 2 RFCs.

Yours,

Ran

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

[RJ Atkinson]

On 02  Apr 2014, at 13:25 , Paul Hoffman wrote:
> That was certainly not the intention.

OK.

>> [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers
>> with forwarding silicon that could parse AH and any other IPv4/IPv6
>> options - at wire-speed for 10 Gbps interfaces - 10 years ago.  I am
>> aware of 2 other very widely deployed implementations with the same
>> ability to parse past AH to read TCP/UDP ports and apply ACLs at
>> wire-speed.  So this is a widely deployed capability, rather than
>> theory. :-]
> 
> That's not an important note for this discussion, ...

Ah, but it is important, because it talks about deployed reality,
and many many users and implementers DO care about the ability 
to apply ACLs.

> which is about what the IPsec community
> has expressed as a general preference.

You are mis-characterising the "VPN community" (e.g. VPNC)
as being the whole "IPsec community".  This I-D supposedly
is NOT a VPN-focused draft, but instead claims to address 
the whole audience of IPsec implementers, users, and usages.

> You feel that preference is wrong, and you have stated
> that in earlier WG discussions.

No.  That is not what I believe or feel, NOR is the quote 
a correct summary what I have expressed in past discussions.
Instead, that is a mis-apprehension of what I have said.

In fact, I don't think that the preference for ESP with an integrated
transform is wrong or bad - for VPN uses.  Indeed, there are 
well-understood and broadly agreed reasons why - for VPNs -
ESP with an integrated transform is preferable.  Further, we all 
agree and understand that VPN is the most widely deployed use case.  
However, it is not the only deployed IPsec use case.  

A general IPsec Requirements document ought to be addressing
all deployed use cases, and ought not be limited to VPN uses.

>> We owe it to readers to be crisp, clear, complete, and accurate 
>> with the text in this draft.
> 
> Yes, but:
> 
>> Candidate new text:
>> 
>>"When no IPv4 options or IPv6 optional headers are present, and 
>>in environments without concerns about attacks based on option
>>insertion (e.g. inserting a source routing header to facilitate
>>pervasive eavesdropping), the IPsec community generally prefers
>>ESP with NULL encryption over AH.  However, some protocols
>>require AH.  Also, AH always protects all IPv4 options and IPv6
>>optional headers, while ESP NULL is unable to protect any IPv4
>>options or to protect IPv6 options that are seen & processed by
>>intermediate systems (e.g. routers, security gateways, other
>>middle-boxes).  Some IP-layer options, for example IPSO [RFC-1108]
>>and CALIPSO [RFC-5570], today are deployed in some environments 
>>while using AH to provide both integrity protection & authentication.
>> 
>>Further, deployed routers from multiple vendors are able to parse
>>past an AH header in order to read upper-layer protocol
>>(e.g. TCP) header information (e.g. to apply port-based router
>>ACLs) at wire-speed.  By contrast, there is no 100% reliable way
>>to parse past an ESP header, although some ESP header parsing
>>heuristics have been documented [RFC-5879] that work in some cases.
> 
> That is neither crisp nor clear; it is more complete;

> it is inaccurate about the parameters that the IPsec community cares about.

Precisely HOW is it inaccurate ?

I believe that everything in my text is accurate.
If there is something inaccurate, please do say precisely what.

> The proposed text comes off as an advertisement for AH, but that's exactly
> the opposite direction that the WG has been leaning for this document.

I'm open to having you or others propose some alternative text, provided
that text makes clear that ESP can't protect IP options in transit, 
while AH can.  This difference in the provided security properties is
entirely factual.  For VPN deployments, this might not matter, but
for other existing IPsec deployments it is known to matter.  Again,
this document is not about a VPN profile of IPsec, it is about the
entirety of IPsec.

> The IPsec community generally prefers ESP with NULL encryption over AH.
> AH is still required in some protocols and operational environments
> when there are security-sensitive options in the IP header, such as
> source routing headers.

This does not make clear that ESP can't protect the IP options,
which is an important-to-document limitation of ESP.

It also should mention IP sensitivity label options, such as RFC-1108 
and RFC-5570 as a use case for AH, in addition to source-routing headers.

Yours,

Ran

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt

[RJ Atkinson]

All,

Working primarily from the HTML diff, towards the end of Section 3, 
the draft -03 text says in part:

 "The IPsec community generally prefers ESP with NULL encryption
  over AH, but AH is required in some protocols; further, AH is
  more appropriate when there are security-sensitive options in
  the IP header"

The 1st part of this assumes that IP-layer options aren't in the
packet (which most commonly is true) and that the deployment threat
model does not consider option insertion attacks to be a major threat
(a widely held belief for the commercial portions of the Internet).

The 2nd part of this is vague, unclear, and a bit misleading.  It
could be read as indicating that ESP with NULL encryption is able to
protect IP header options, but AH is preferred for that case.

In fact, ESP is *NEVER CAPABLE* of (A) protecting IPv4 options or 
(B) of protecting IPv6 options that are seen & processed by 
intermediate systems (e.g. routers, security gateways, other 
middleboxes).  ESP also NEVER can prevent option insertion attacks.

Lastly, it is ALWAYS possible for an intermediate system (e.g. router
with ACLs) to parse past the AH to see transport-layer headers, 
but even the best of the heuristics for parsing past an ESP header 
are not 100% reliable.

[IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers
with forwarding silicon that could parse AH and any other IPv4/IPv6
options - at wire-speed for 10 Gbps interfaces - 10 years ago.  I am
aware of 2 other very widely deployed implementations with the same
ability to parse past AH to read TCP/UDP ports and apply ACLs at
wire-speed.  So this is a widely deployed capability, rather than
theory. :-]


We owe it to readers to be crisp, clear, complete, and accurate 
with the text in this draft.


Candidate new text:

 "When no IPv4 options or IPv6 optional headers are present, and 
 in environments without concerns about attacks based on option
 insertion (e.g. inserting a source routing header to facilitate
 pervasive eavesdropping), the IPsec community generally prefers
 ESP with NULL encryption over AH.  However, some protocols
 require AH.  Also, AH always protects all IPv4 options and IPv6
 optional headers, while ESP NULL is unable to protect any IPv4
 options or to protect IPv6 options that are seen & processed by
 intermediate systems (e.g. routers, security gateways, other
 middle-boxes).  Some IP-layer options, for example IPSO [RFC-1108]
 and CALIPSO [RFC-5570], today are deployed in some environments 
 while using AH to provide both integrity protection & authentication.

 Further, deployed routers from multiple vendors are able to parse
 past an AH header in order to read upper-layer protocol
 (e.g. TCP) header information (e.g. to apply port-based router
 ACLs) at wire-speed.  By contrast, there is no 100% reliable way
 to parse past an ESP header, although some ESP header parsing
 heuristics have been documented [RFC-5879] that work in some cases.


Yours,

Ran Atkinson

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

[RJ Atkinson]

On 03  Mar 2014, at 17:53 , Paul Wouters wrote:
> On Mon, 3 Mar 2014, RJ Atkinson wrote:
> 
>>> ESP-NULL offers the same protection as AH, ...
>> 
>> This sentence above is not true.  ESP-NULL and AH provide
>> different security properties to the IP-layer.
>> 
>> AH protects all IP options, whereas ESP cannot protect any
>> IP options that appear prior to the ESP header -- the location
>> in the packet where those IP options are seen *and acted upon*
>> by routers/firewalls/etc.
> 
> What meaning has "protecting" those bits? Endpoint A and B protect
> something by cryptography, but any router in the middle can't trust
> those signatures anyway. So I don't see how AH is different from
> ESPinUDP where you set those options in the UDP header. These are
> not "protected" but the router can't verify the crypto anyway.

At least some deployed routers in the middle in some deployments
ARE able to validate and therefore trust the AH values (and trust 
that the IP options present were placed there by the sender).  This 
was ALWAYS something that was designed-in to AH (RFC-1826, Section 1.1).  
Some other kinds of middleboxes (e.g. some firewalls) also can do this.

Some AH implementations that support asymmetric keying go back 
at least 15 years, although those were not standardised back in 1995 
-- primarily due to IPR considerations on intermediate authentication
(which IPR I believe either has expired or expires very soon).  

>> Similarly, AH protects many IP header fields from in-transit
>> modification, whereas ESP encapsulation provides no protection
>> for the 1st (outer) IP header (i.e., that appears before the ESP header).
> 
> So I don't buy that. The IP header is not protecting the packet from
> a router, which cannot confirm the crypto of that protection.

Some deployed IPv4 routers can confirm the AH authentication information
in some deployments.  This has been true for years.  

Note that RFC-1826, Section 1.1, contains explicit discussion of the 
applicability of AH with asymmetric algorithms to enable intermediate 
authentication.

> What this
> is really about is exposing things like QoS bits,

No.

IETF standards say that the IP ToS/DiffServ bits are allowed 
to be modified in-transit.  For example see Section 7.2 of 
RFC-2474 & also page 10 of RFC-2402.

> but those devices
> acting on those are not verifying any "protection". They are blindly
> using the exposed options.  So ESPinUDP works equally well here.

No. 

>> As a prior discussion has noted, AH can and is used to provide
>> cryptographic protection to some security-critical IP options
>> (e.g. sensitivity labels).  ESP-NULL is not capable of protecting
>> those options.
> 
> I'm not sure what you are referring to here. Not labeled IPsec I
> take it? And again, how does this "protection" work? How do the
> routers verify this "protection" when only the endpoints know
> the crypto keys used to protect the header and payload?

As an example, one can have (and real deployments exist) where
an IPv4 sensitivity label (e.g. FIPS-188) in an IPv4 packet is 
protected by AH, using asymmetric cryptography, where both 
end systems and also intermediate label-policing IP routers can 
validate the digital signatures carried by AH to validate that
the sensitivity label has not been tampered with since it was
placed in the packet by the sender.  Not all deployments where
FIPS-188 is in use also use/deploy AH for protection, but some
FIPS-188 deployments definitely do.

- ESP-in-UDP can NOT do this.  
- ESP-NULL can NOT do this in any other way either.

> Can you explain how this protection works? If an AH packet flies by,
> and I change the QoS option from off to on to give my packet preference
> in the network, how will the next router notice this and ignore
> this QoS option?

As noted above, the IP ToS/DiffServ byte explicitly is excluded
from AH protection, originally because some deployed routers were 
known to change the field in-transit (RFC-2402) and later (after 
RFC-2474) because IETF standards explicitly say that modifying 
that field in-transit is allowed.

>> Some deployments definitely do care.  Other deployments do not.
> 
> By understanding was always that people didn't like options getting
> "lost" or "hidde" within the ESP payload, and not getting set on
> the outer packet.

While some people might have that view, 
that never has been a universal view.

Broadly speaking, the primary case against using any IP option
is that *historically* the presence of an IP option in an IP 
packet caused that packet to be forwarded on the "slow path"
of many commercial IP routers.  That is not necessarily the case
today, although it report

Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

[RJ Atkinson]

> Perhaps some text along the line of:
> 
>   ESP-NULL offers the same protection as AH, ...

  This sentence above is not true.  ESP-NULL and AH provide 
different security properties to the IP-layer.

  AH protects all IP options, whereas ESP cannot protect any 
IP options that appear prior to the ESP header -- the location
in the packet where those IP options are seen *and acted upon* 
by routers/firewalls/etc.

  Similarly, AH protects many IP header fields from in-transit
modification, whereas ESP encapsulation provides no protection
for the 1st (outer) IP header (i.e., that appears before the ESP header).

  As a prior discussion has noted, AH can and is used to provide
cryptographic protection to some security-critical IP options
(e.g. sensitivity labels).  ESP-NULL is not capable of protecting
those options.  

  The reason AH is MAY is that not all deployments care about
protecting the (outer) IP header and (visible to the forwarding
plane) IP options.  Some deployments definitely do care.  Other
deployments do not.

Yours,

Ran

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec

[RJ Atkinson]

I agree with Steve Kent's recent postings about this draft.

Ran

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] WESP and reliability

[RJ Atkinson]

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

> On Jan 4, 2012, at 10:37 AM, RJ Atkinson wrote:
>> 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.
> 
> 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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 04  Jan 2012, at 09:18 , Bhatia, Manav (Manav) wrote:
>> 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.

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 04  Jan 2012, at 00:49 , Nico Williams wrote:
> 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.  

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
> reasons to still use it, then maybe not.

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Aside: IPsec History

[RJ Atkinson]

Earlier, Michael Richardson wrote:
> Ran, as you've been rather inactive in IPsec,

Fair point.  
I mostly watch without writing notes.
IPsec hasn't been paid work for me since 1995,
(and isn't paid work now -- just community service).

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

People I worked with wrote most of the IPsec code,
for example two other folks were responsible for 
inventing and implementing PF_KEY, but the original 
specification work was mine -- and was very directly 
derived from NIST publications describing earlier
work done by the SDNS Project to develop the SP3D 
protocol.  

If one looks at the original I-D for what became ESP, 
the packet format there is identical to SP3D.

Our funding came from ARPA/CSTO, who were funding 
rather a lot of Internet R&D at that time, and 
from the Space & Naval Warfare Systems Command.  

Since this caused me to look back, I'll also note
that the use of AH to authenticate IP options and
prevent certain attacks is clearly documented by
the 2nd paragraph on Page 10 of RFC-1826.  Some
other limitations inherent with tunnels are noted 
in the 3rd paragraph on the same page.

Cheers,

Ran

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 02  Jan 2012, at 20:06 , Nico Williams wrote:
> On Mon, Jan 2, 2012 at 6:45 PM, RJ Atkinson  wrote:
> With tunnel mode you effectively repeat the options inside and outside
> 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
> path then the recipient can see that options were modified.

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

>>>>- ESP null cannot reliably be parsed past.
>>> 
>>> 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.
> 
> Sure, this is necessarily true until any replacement for AH is
> 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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 02  Jan 2012, at 19:54 , Bhatia, Manav (Manav) wrote:
> And most of these are considered dangerous and are generally discouraged.
> 
> 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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 02  Jan 2012, at 19:51 , Bhatia, Manav (Manav) wrote:
> 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.

> 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

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

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

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 02  Jan 2012, at 19:21 , Jack Kohn wrote:

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

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

Ran

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 02  Jan 2012, at 19:28 , Nico Williams wrote:
> On Mon, Jan 2, 2012 at 3:11 PM, RJ Atkinson  wrote:
>> 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 in tunnel mode is supposed to be the replacement for AH,
> and gets you this.

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.  

>>- ESP null cannot reliably be parsed past.
> 
> 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.

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

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

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

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

Earlier, Dan Harkins wrote, in part:
> 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 foo" 
> 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.

+1


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 02  Jan 2012, at 18:25 , Jack Kohn wrote:
>> Similar IPv6 examples exist.
> 
> And i would like to know what those are.
> 
> 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:



Yours,

Ran

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 02  Jan 2012, at 14:24 , Jack Kohn wrote:
>> 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:
> 
> 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


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

On 02  Jan 2012, at 10:16 , Bhatia, Manav (Manav) wrote:

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

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.

> 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

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

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

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

The text in your two drafts on the topic.

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

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.


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

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

Yours,

Ran

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Avoiding Authentication Header (AH)

[RJ Atkinson]

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:



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: