[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Death to AH (was Re: SA identification)



#<text/plain
 In your previous mail you wrote:

   In fact, I don't understand why you think that "death to AH!" means
   "IPsec is for VPN only"; they seem to me like two completely separate
   issues.

=> I don't know if you were in the mobile-ip room this morning but
this was very clear (if you weren't I believe the slides will be
available soon). As no IPsec people did object to Jeff's written claims
about what IPsec can/should use for, I assume they are right and
perhaps (so I ask) reflect a common opinion. I apologize if you didn't
in the room as the claims are far more than "death to AH!"

Regards

Francis.Dupont@enst-bretagne.fr

PS: issues are not so separate, AH lovers are not in favor of VPNs only.
PPS: IESG security concerns with MIPv6 are available, I've attached them.
#<text/plain
Message-Id: <200103192035.f2JKZU501536@hygro.adsl.duke.edu>
To: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] IESG security concerns with MIPv6
Date: Mon, 19 Mar 2001 15:35:30 -0500
From: Thomas Narten <narten@raleigh.ibm.com>
List-Archive: <http://playground.sun.com/mobile-ip/>

This is a note to summarize some security-related concerns that the
IESG has with the Mobile IP v6 Draft
(draft-ietf-mobileip-ipv6-13.txt). The concerns can be summarized as
follows:

The IESG has concerns about the draft's dependency on IPSEC AH to
authenticate Binding Updates. There are several issues here.

   a) There is significant overhead associated with building and
      maintaining AH/IPsec SAs (both in terms of state that needs to
      be maintained, but also in terms of required message flows, and
      the processing required to implement those flows). This has
      negative implications for larger servers that process many 100s
      of thousands of connections at a time.

   b) The processing rules for authenticating a Binding Update with AH
      are complex and are apparently not readily supported by the
      current generation of IPsec/IKE implementations (e.g., the IPsec
      policies are needed that specify sufficient granularity about
      IPv6 packets containing binding updates). There is a concern
      that this will not be rectified in the short term or that
      providing this level of granularity is even approriate for
      IPsec, leading to a possible result that the Binding Update
      won't be implemented/supported at all, (or even worse) that it
      will be used without proper authentication.

The IESG strongly recommends that the WG find an alternate approach
that is not tied to IPsec/AH. Our recommendation is to consider
approaches that are Binding Update specific, so that a solution can be
tailored to meet the actual requirement at hand. The main requirement
that needs to be met is that the use of MIPv6 with Binding Updates be
no less secure than the level of security one currently has with IPv4
(without mobility). That does not mean that the protocol needs to be
immune to *all* types of vulnerabilities. Rather, it means that a
solution should not introduce significant new vulnerabilities that are
not present in IPv4 today. (Of course, reducing vulnerabilities
compared to IPv4 is a very desireable goal.)

The WG is encouraged to look at the ID
http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
It was developed specifically as an alternate approach to addressing
the problems discussed in this note.

Jeff Schiller will give a brief presentation on the approach discussed
in the ID during the Mobile IP session at Minneapolis. The WG chairs
will likely be forming a design team to work on a specific solution to
the identified problems. This also will be discussed at the Thursday
session.

Thomas


Follow-Ups: References: