Subject: [mobile-ip] I-D ACTION:draft-mkhalil-mobileip-ipv6-sap-00.txt

From: [email-masked]
Date: Mon, 02 Apr 2001 07:15:34 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Dynamic Security Association Establishment Protcol For
                          IPv6
	Author(s)	: M. Khalil, H. Akhtar, E. Qaddoura
	Filename	: draft-mkhalil-mobileip-ipv6-sap-00.txt
	Pages		: 14
	Date		: 30-Mar-01
	
A protocol is proposed to allow a fast establishment of Security
Association between the Mobile Node (MN) and Correspondent Node (CN).
Once this Security Association is established, it can be used to
authenticate any Binding Update between the MN and the CN.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mkhalil-mobileip-ipv6-sap-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-mkhalil-mobileip-ipv6-sap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-mkhalil-mobileip-ipv6-sap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 2 Apr 2001 07:16:55 -0500

Hello, 

1).  This draft belongs in the security working area of the IETF.

2).  The MIP group is not qualified to make a security assesment of this draft.

3).  Why should the security association between an MN and a CN be all
       that much different from other types of clients and servers and peers
       that run on the Internet?  Why enmesh the security terminology with
       MIP terminology?  (cohesion is still a bad design choice after all these
        years).  Build a generalized solution for the Internet that MIP can use.

4).  In the Abstract,  How fast is "fast"?  What is the baseline?

5).  Can't a security association be used for all sorts of other good stuff besides
       MIP binding updates (related to 2 above).

6).  As for the rest of the draft, I saw no references to the specific Diffie Hellman
       work you were applying, no references to patents you were using (expired
       or not), I saw one vague reference to some of Charlie's work, I am
       supposed to believe that this work will lead to something cryptographically
       secure? 

       I believe this type of work needs to be reviewed in the MIP WG after it
       goes through some severe scrutiny in the security area where there
       are domain experts in security.  Most people in the MIP WG want 
       mobile security in the worse way, but are not security domain experts.

Best Regards,

Phil

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 02 Apr 2001 07:50:21 -0700

Hello Phil,

I haven't read MK's draft, but some of your points are at odds
with recent events, at least to my understanding.

> 2).  The MIP group is not qualified to make a security assesment of this draft.

Who else has the time or charter to do it?

>         years).  Build a generalized solution for the Internet that MIP can use.

Unfortunately, we've just been made very aware that Binding Updates _cannot_
use any generalized IPsec solution.  This is a very long subject, but the
very short version is that existing implementations cannot do the right
thing according to the way they look up entries in their SPDs.
 
>        MIP binding updates (related to 2 above).

Apparently not!

>        mobile security in the worse way, but are not security domain experts.

But we have some examples to work from.  For instance, RFC 2002 has
enough security to make Mobile IPv4 work.  I think after the current
round of fulfilling IESG design requirements, we'll have a couple of
other useful tools in the closet.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Apr 2001 12:17:39 -0700 (PDT)

> thing according to the way they look up entries in their SPDs.

   I don't think that's what has been said at all.
   There are three overall problems with IPsec in the
   mipv6 draft that I know about:

   1) Use of AH for a destination option is a little
      dodgy. I believe that was Bill Sommerfeld's
      comment. However, using ESP/NULL for a BU
      which wasn't destination option (ie, just
      make it a separate ICMP, say) wouldn't be
      problematic on that front.

   2) For the general anonymous browsing kind of 
      problem which is the general case for MN->CN
      communication, the implications of global
      PKI's inherent for key exchange
      are... daunting to say the least, and quite
      possibly undesirable even if possible. A
      more decentralized approach would be better
      if possible

   3) There are performance implications for large
      servers, both in round trips and CPU
      complexity using IKE (or even KINK) that
      we'd like to have a way to opt-out if 
      possible. To some degree this is a cop
      out and only postpones when we won't be
      placing packets over insecure links, but
      it's also today's reality. I'm sort of 
      ambivalent on this point.

   That said, I still think it would be very
   useful to still salvage the ability to use
   IPsec for BU's (mostly by fixing (1)). For the
   other considerations, we're going to need
   something different.

		 Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 2 Apr 2001 12:37:41 -0700 (PDT)

In general, anything that requires upfront public
key operations needs to consider the possibility
of make-work DoS attacks. If I can send you an
unauthenticated message with little or no work
which causes you to expend a lot of work, then I
have a very nice attack amplification mechanism.

There has been considerable debate about this in
IPsec and to my knowledge is still not resolved.
My perception is that IKE, in fact, still has it
wrong (I believe that it's generally accepted that
photurus got it right, and that son-of-ike should
fix this problem). I do not claim to understand
this space very well -- the solution seems to 
involve puzzles and other odd creatures -- but
I do know that any MIPv6 solution for BU's MUST
contend with this problem. Avoidance, IMO, is
the best way to contend with it.

	     Mike