Subject: RE: [Mip6] New Draft with Bootstrapping Protocol

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 6 Dec 2004 18:32:19 +0100

hi james,

thanks for your quick response. please see my comments inline:

> > this is an interesting document. you might remember my 
> non-published 
> > draft which i have sent to the bootstrapping design team 
> mailing list 
> > which basically said "use ikev2 if you want to establish an 
> ipsec sa". 
> > after we wrote the bootstrapping problem statement draft 
> there is very 
> > little meat left apart from saying: use ikev2 (with all its 
> features)
> >
> > so,
> > why do you need a draft?
> >
> 
> For one, to specify the DNS SRV RR format for finding the HA 
> address. I actually don't recall your draft, did it say 
> anything about using DNS SRV?
no, i think i haven't. i need to check. 

i pointed to the work done in the 3gpp with regard to this issue (in the
area of wlan/3g interworking). is your proposed based on the 3gpp approach?
there is also work in the v6ops group on tunnel endpoint discovery which is
very similar (since the the home agent is also a tunnel endpoint).

> This is important for interoperability. For two, to give a 
> more detailed description of how to use IKEv2. For example, 
> using the NAI for identity, and what IKE identity type. This 
> could also be useful for interoperability.
hmm.  
if you use eap authentication then you need to use the nai anyway. there was
some discussion about a nai identity type (on the ipsec mailing list) and
people believed that the  ID_RFC822_ADDR is sufficient. there don't seem to
be too many choices.  

regarding public key based authentication of the responder to the initiator
you might want to take a look at: 
http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-eap-auth-02.txt

furthermore, we have provided some details ipv4/ipv6 transition with ipsec
at:
http://www.ietf.org/internet-drafts/draft-tschofenig-v6ops-secure-tunnels-02
.txt
(although this document has a different scope; it also points to tunnel
endpoint discovery)

> And for three, to give an alternative for cases where AAA is 
> not available, as I stated in the email message.
this is certainly an interesting issue - probably also for the enroll
working group. 
i guess you refer to section 2.1 (UMA) where bootstrapping is provided with
the help of a web page. this aspect is also known from the v6ops area where
you can configure your tunnel broker using a web page.

ciao
hannes

>             jak

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Dec 2004 09:54:33 -0800

> very similar (since the the home agent is also a tunnel endpoint).

Yes, I'm aware of the 3GPP work, but this isn't related. Perhaps the v6ops
tunnel discovery would be another option, it sounds worthy of further
investigation.

> (although this document has a different scope; it also points to tunnel

Thanx for the references.

> you can configure your tunnel broker using a web page.

Yes, that's the idea. Most hotspots today in the US and some I've used in
Europe and Japan don't use EAP. Also, there's the enterprise and
nonintegrated mobility service provider examples. You'll recall that we
discussed the nonintegrated case in the problem statement design team. An
EAP on network entry bootstrapping approach won't work for that case.

            jak

---

From: Marc Manthey <[email-masked]>
Date: Mon, 6 Dec 2004 18:54:06 +0100

> area of wlan/3g interworking). is your proposed based on the 3gpp  
there is a lot of discussion in a few apple lists too.
 From my point of view is 3gpp one of the most importand things for
the content provider market.
> very similar (since the the home agent is also a tunnel endpoint).
this takes a lot of bandwith
>> could also be useful for interoperability.
exactly
> http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-eap-auth 
there are some documents here too <http://www.synack.net/xinetd/>
<http://files.dns-sd.org/draft-dns-update-leases.txt>
<http://files.dns-sd.org/draft-nat-port-mapping.txt>

> (although this document has a different scope; it also points to tunnel

tchö
marque
-- 
"It doesn't matter who you are, it's what you do that  takes you far"
  —Madonna.

          M. Manthey
          http://brain.let.de

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Dec 2004 10:23:56 -0800

><http://files.dns-sd.org/draft-nat-port-mapping.txt>

OK, thanx, I'll check them out.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Dec 2004 12:41:57 +0100

James Kempf wrote:
> Yes, that's the idea. Most hotspots today in the US and some I've 
> used in Europe and Japan don't use EAP.

Me too.  But.

Connecting a v6/v4 laptop to a completely v4 hotspot has no implications
from the hotspot using or not using EAP.  What's sure is in this way the
v6 part of the laptop will most certainly _not_ use EAP, regardless of
the v4 hotspot using or not using EAP.  This is so because EAP is bound
to L2 and a v6 laptop over that v4 hotspot has no L2 for that v6 (it's a
tunnel).  So I somehow agree with your thinking.

Also, if anyone is aware of any v6 native hotspot area commercial
service for public (or in trial period in perspective of selling to
public), please let me know; I only know about such v4 spots.

Alex