SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...)

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Steve and Tero,

[Taking my SEND WG chair hat firmly *off*, i.e., speaking for
  myself only.]

Stephen Kent wrote:
> Until SEND has a comprehensive, coherent model for using AH that does
> not require changes to other parts of IPsec processing, ...

With all respect, I sincerely believe that SEND will never come up
with "a comprehensive, coherent model for using AH that does
not require changes to other parts of IPsec processing".  More on that
below.  If you disagree, please try to come up with a scheme where
you use AH when you

  - don't have any IP addresses (i.e. during IPv6 DAD)

  - do not know in which network you are (public access)

  - do not trust most nodes in the network (public access)
    - and are still trying to figure out what node(s) to trust,
      how much, and in which respects

  - do not know which of the potentially many trust roots you
    should use to establish trust with the possibly existing
    trusted nodes in the otherwise untrusted network

  - want to operate, at a lower level of security, when you
    are unable to establish pre-configured trust with anyone

  - want to make this all *effectively*, without using zillions
    of messges, since you potentially have to do this each time
    you roam to a different IP network

I still claim that there are situations where the integrity and
data origin authentication of the IP header is important.
Hence, I firmly believe that the text concerning the relationship
between AH and ESP is misleading at best and perhaps even outright
wrong.  Using tunnel mode is not an answer, at least sometimes.

>> - In the current SEND WG proposal, the SA does not indicate the key
>>   to be used.  Instead, the AH header itself contains the public 
>>   key.  ....
>> 
> This is not consistent with the IPsec specs!

Actually I more or less agree with you, Steve!  Indeed, that is
one of the reasons why I am proposing changes to the current AH
usage in SEND, basically moving the public key from the AH header
to a separate extension header, to be placed before the AH header.
(See the separate discussion at the SEND WG ML.)

> In IPsec, the SAD entry for an SA stores the keys that are employed
> to process packets. In turn, the SAD entry is located by using the
> SPI from an inbound packet (for unicast traffic).

I am very very well aware of that.  I quite well remember what
I learned while I implemented one of the early BITS IPsec stacks
as a part of my PhD work back in 1994-1995.

However, sometimes the SPI alone is not very useful, and sometimes
using the destination address as a selector is not the right choice.
(More on this on the separate thread.)

> If SEND wants to use AH then you need to use the protocol (including
> the processing spec) as defined in IPsec, not just the syntax from
> 2402. Suggesting that we change AH to accommodate SEND's possible use
> of it, in a fashion not consistent with the current specs, is asking
> quite a lot.

I agree.  Actually, using the revised suggestion of moving the
public key from the AH header to a separate extension header,
thereby creating an "implicit" or "inline" one message KMP,
seems to simplify issue.  However, even in that case it
would really make sense to perform SA selection based on the
source address.  However, I defer that discussion to the other
thread.

Tero Kivinen wrote:
> The SEND is a user of the AH. ... Do we want to say to our
> (only?) user that no we do not allow you to do anything differently?

As Itojun pointed out (and Steve well knows), SEND is indeed not
the only user of AH.  Anyway, thanks for your supporting words.

We should also remember that RFC2461/2462 explicitly states that
AH is the method to be used for protecting IPv6 ND.  That is, in fact,
quite doable if you have a static environment with pre-configured
security associations, PK based or symmetric.  However, once you
want to use AH in the public access environment, things get harder.
See the outline above.

> Do we want them to create another protocol replacing their use of AH?

This is the very question.  There are lots of folks at the
SEND WG who believe so.  That is, they believe that AH should
not be used for securing IPv6 ND, and a separate protocol should
be developed instead.

> Another people who have been saying that they want to use AH is 
> Mobile IP people. What do they want? Is the current spec fine with 
> them or do the want similar processing than SEND?

Having been there too (though recently not very actively), I strongly
suspect that some of the MIPv6 requirements will be fairly similar
to those of SEND.  Both deal with IP address mappings, MIP with
IP -> IP mappings and ND with IP -> lladdr mappings.

> Is there any use for the AH as it is now specified?
> What are application(s) / protocol(s) which will use it?

I think Itojun answered to these.

> If we cannot answer to those questions I think we should drop the 
> current AH from the IPsec WG and say that SEND/Mobile IP etc can 
> specify it so that it will be suitable for them :-)

Thanks.  See the other thread at saag.

> I do NOT see any use for the AH on the VPNs or road
> warriors IPsec clients.

Here I tend to agree with you, Tero, but that is really beside
the point of this discussion, IMHO.

--Pekka Nikander