Subject: RE: [mobile-ip] list of things for MIPv6

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 21 Dec 2001 18:42:23 +0100

>         a. new extension header 
>         b. Authentication Sub-Option only. 
>         c. Jari Arkko's draft, option 4 which shows how 
>            authentication suboption and AH can be used 
>            together with minimal changes. 
> 
>         if we decide to go with (a), lets not go with UDP. 
>         instead we should use a new extension header. 
>         I personally prefer option (c). Implementing the 
>         auth suboption is very easy. I can provide the code 
>         if people think it is complicated to implement. 
> 
I thought the group had already settled on b. Last time I checked there were even plans to upgrade various open-source implementations as well. 

=> That was optimistic thinking I think ! we never
had a concensus call on this.

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Dec 2001 10:30:57 -0800

one small comment.

> had a concensus call on this.

option (b) is very simple and works really well. 
all it needs is IKE supplying the keys. 

imagine this.

1. weak authentication can supply the key for the
   auth sub option
2. IKE can supply the key for the auth sub option
3. you dont have to worry about a new extension
   header for the BU. 
4. you dont have to worry about IPSec and piggybacking.

sigh(!) there are so many advantages... people just dont
want to see it.

also please take a look at the Jari Arkko's old mail
that I forwarded to the mailing list yesterday. IKE
can be used to create keys for the auth sub option. 

if the IPSec WG says they dont want to work on (2),
then lets go with option (c). use both the sub option
and AH.

Vijay

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Dec 2001 12:48:19 -0800 (PST)

> all it needs is IKE supplying the keys. 

   This is *far* more complicated than you are
   making it out to be. Anybody who claims that
   changing IKE -- and IKE is *not* the only
   consideration -- would do well to find out 
   what is going on in the IPsec working group.
   Making tweaks for MIP is not even *vaguely*
   on their radar screen, nor is it clear that 
   the WG would ever take it up.

   Changing MIP to fit IPsec is a *far* easier
   path, and one that MIP WG is completely in
   control of their own destiny.

	  Mike

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 21 Dec 2001 16:06:11 -0500

>    what is going on in the IPsec working group.

It has been that IKE is "cast in stone". Luckily however,
IKE is in the process of being changed, as we speak.

IPSec working group is working on a successor of IKE, and 
now is the time to submit any specific requirements for IKEv2.
-- 
Regards,
Uri.
-=-=-<>-=-=-
<Disclaimer>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Dec 2001 13:14:20 -0800

>    what is going on in the IPsec working group.

actually I did that. IPSec WG is currently working on
a requirements draft for son-of-IKE. I was surprised
that SCTP folks were able to add a couple of requirements
to make IKE work with SCTP. One of them I remember was
that son-of-IKE now should support multiple addresses 
instead of a single address. I believe this was needed 
for SCTP to work.

I was also talking to another person who is quite 
active in the IPSec WG. his personal opinion was 
that IPSec WG wouldnt be against taking on 
additional requirements. (also becuase they would
really like to see IKE being implemented and 
deployed widely).

I was thinking maybe could do something like this. So 
I mailed the IPSec WG chair Theodore T'so. I mailed a 
few other people too in the IPSec WG. havent heard from 
them yet.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Dec 2001 13:21:38 -0800

> now is the time to submit any specific requirements for IKEv2.

Exactly!! two options here.

1. Increase the selector granularity. Destination option
   type should also be a selector.

2. Add Authentication sub option to AH and ESP as protocols
   which need keying by IKE.

Choosing 1 would be great. without it, IPSec is effectively 
killing the use of destination options becase they can never 
be protected specifically. It would good if the extension 
headers could be used more widely instead of always using 
a port number for selecting a particular SA.

regards
Vijay

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 21 Dec 2001 13:25:54 -0800

> now is the time to submit any specific requirements for IKEv2.

I was recently talking with someone involved in the work refered to
above and he was surprised none of the requirements from here were
known to them. In fact, the work is in an advanced stage so it won't
necessarily take years before the revised APIs could be available.
IPsec interfacing seems to me to be a manageable database API problem,
its implementation is not rocket science, it has mainly been taken
too much "given" that absolutely nothing can be changed there.

BR,

-Jari

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 17:24:46 +0100

>about BU protection, (b) is Authentication Sub-Option only.

=> argh! I have two strong objections:
 - if piggy-backing is used ((a) new extension header simply makes
   piggy-backing impossible) you can get all the IPsec for another
   reason huge complexity.
 - IKE is Diffie-Hellman with strong authentication,
   as strong authentication mandates a global PKI (nobody
   knows how to do it without, specially in the IKE case)
   there is like a problem here...

Regards

[email-masked]

PS: IKE is a pig, left it to IPsec people. Even for the MN-HA security
association(s) IKE should be replaced by better tools (like AAA as described
in AAA for Mobile IPv6 drafts).

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 18:00:16 +0100

It would good if the extension 
   headers could be used more widely instead of always using 
   a port number for selecting a particular SA.
   
=> the only advantage will be to give more control to applications
in the use of IPsec (i.e. in place of hacking the SPD, an application
can just use a "please-protect-me" destination option.
But in the BU protection context, this will only raise again the
piggy-backing issue (i.e. two different policies for the same packet
for maximal confusion).

Regards

PS: does this work well with the proposed IPsec implementation
for Solaris (cf. very old mails about IPsec and piggy-backing)?

---

From: Michael Thomas <[email-masked]>
Date: Sat, 29 Dec 2001 13:06:52 -0800 (PST)

> had a concensus call on this.

   Indeed. The next rev of the mip draft should have
   *all* of this pulled out until there is consensus.
   What is in there is *highly* misleading and was
   put in the draft without any consultation on the
   list, and came as a rather rude surprise to some
   of us who have been participating in this
   discussion.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 29 Dec 2001 13:29:25 -0800 (PST)

> now is the time to submit any specific requirements for IKEv2.

   IKE is not the only way to key IPsec SA's.

       Mike