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

["James Kempf" <kempf@docomolabs-usa.com>]

Just to clarify a bit to what Pekka has said (and with my SEND WG
chair hat on).

Mobile IP faced some similar issues to what SEND is currently facing
in the area of securing binding updates to correspondent nodes, which
caused them to abandon AH and develop a new protocol.

In SEND, we have a reasonably complete design using AH based on a
reserved SPI that would work with RSA, but it does require an
implementation for the SA that behaves somewhat differently from the
two standard cases of a manual SA or an SA established with IKE. Pekka
has suggested some baseline changes in the design that would reduce
the IPsec implementation work, so most of these differences are due to
the fact the public key is being used, some are due to other factors
around the particular application. Depending on what you believe the
reserved SPI were for, this could be viewed either as an unnecessary
complexity or an extension.

That said, there is strong feeling from some security-knowledgable
SEND WG members and a major vendor that reviewed the initial design
that too many changes would be required in IPsec, and that SEND should
also develop a new protocol. We'll be discussing a proposal from Jari
Arkko on the list and at the meeting to use ND options rather than AH,
despite the fact the AH was specified in RFC 2461/2462. This is
something we've been very strongly trying to avoid, since the intent
of SEND was to be very conservative. There is no concensus in the WG
at the moment about which way to go, since we've just begun the
discussion.

Now removing my WG chair hat and more or less quietly and
inobtrusively slipping on my IAB hat (but not, of course, in any way
speaking for the IAB), these two cases where AH has been tried to
secure IP signaling traffic and found significant difficulties suggest
that there might be a more fundamental problem involving securing IP
signaling that might benefit from some additional attention. From
Ito-jun's email, it sounds like he has examples of cases where AH out
of the box works with securing BGP updates, so the perhaps there is a
class of IP signaling security problems that can be solved by AH.
Knowing the boundaries of that class might be helpful.

            jak

----- Original Message -----
From: "Pekka Nikander" <pekka.nikander@nomadiclab.com>
To: "Tero Kivinen" <kivinen@ssh.fi>
Cc: "Stephen Kent" <kent@bbn.com>; <ipsec@lists.tislabs.com>; "SEND
WG" <ietf-send@standards.ericsson.net>
Sent: Wednesday, June 18, 2003 12:14 AM
Subject: SEND vs. IPsec AH (was Re: Comments on
draft-ietf-ipsec-rfc2402bis-03.txt...)


> 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
>
> --------------------------------------------------------------------
> To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
> body to <ietf-send-request@standards.ericsson.net>.
> Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
> --------------------------------------------------------------------
>