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

[Tero Kivinen <[e-mail]>]

RJ Atkinson writes:
> > 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 ?

I think you are wrong there. VPN uses cases do not use ESP NULL (nor
does it use AH). In all VPN cases the encryption is the important part
there. I do not really see anybody running VPN tunnels in the internet
using ESP NULL (or AH).

As Paul said if this would be VPN specific then it would not say
anything about AH or ESP NULL.

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

ESP in tunnel mode can protect end to end options without any
problems, and also protects the whole inner IP header. ESP cannot
protect options which are used by the intermediate devices, but on the
other those intermediate devices do not have the keying material to
verify the authentication header anyways so whether AH or ESP NULL is
used it does not matter.

And if the intermediate devices do have the keying material then they
can even parse through ESP NULL too as they do know the parameters.

The main problem with the AH is that it does not work with NATs which
makes its use in lots of environments difficult in the internet. It
does work in the enterprice or other controlled environments.

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

As those options cannot be protected in transit with AH or ESP NULL
without sharing the keying material to the intermediate devices, I see
no point of listing those. 

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

I see no point of adding those citations, nor adding those examples.
-- 
[e-mail]