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

[Stephen Kent <kent@bbn.com>]

At 10:14 AM +0300 6/18/03, Pekka Nikander wrote:
>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 don't disagree that SEND has a number of security constraints with 
which it must deal. However, AH was not designed to address this set 
of constraints and thus trying to twist AH to meet the needs of SEND 
is inappropriate.

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

The IPsec WG does not seem to share this view, based on previous, 
extensive discussions. We rarely have circumstances where AH makes 
more sense than ESP in either tunnel or transport mode. And, there is 
a strong desire in the WG to simplify the IPsec specs, which runs 
counter to your suggestion.

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

There is NO public key in the AH header. There is a place for an ICV.

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

I don't think this WG  has identified a set of contexts in which the 
current SA selection mechanisms are not sufficient.  We made some 
changes to accommodate MSEc requirements, but it's very late in the 
process to assert that there needs to be fundamental changes to this 
mechanism.

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

As noted above, there was NEVER a provision to carry ANY key in the 
AH header, so this whole thread seem rather odd to me.

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

The RFC numbers cited above obviously refer to specs issued after the 
IPsec specs were published.  I don't think the IPsec WG can be 
responsible for what other WGs may choose to say about how to use the 
protocols developed here, but I think it fair to say that maybe 
someone made an assertion without thinking it through.

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

I'm all in favor of that, if the alternative is to make the sort of 
changes you suggest to AH, to accommodate SEND requirements.

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

We have had interactions with folks about mobile IPv6 and its uses of 
IPsec. A previous version of the ID was held up in the IESG because 
it seemed to suggest changes to IPsec that had not been agreed to by 
this WG.


Steve