Subject: RE: [Mip6] bootstrap problem definition

From: Giaretta Gerardo <[email-masked]>
Date: Mon, 16 Feb 2004 17:25:15 +0100

Hi Jari,

I read your problem statement and have some questions:

1) In section 3.2.1 you say that "...IKEv1 does not contain support for exchanging the right kind of information, primarily the NAI, with the mobile node.". Instead, rfc2407 and rfc2409 state that, when using aggressive mode and pre-shared key, it is possible to use the ID_USER_FQDN (i.e. user@domain) as peer identifier for IKE phase 1. That could be used as the identifier of the MN (in place of the home address) during IKE phase 1 negotiation with the HA, thus allowing for the interaction with a backend AAA server. Am I missing something?

2) In section 4 it is not completely clear to me the descrition of the third scenario. What is the existing security association you are referring to? Is it the SA in place between the MN and the AAA server of the home domain? 

Bye,
--Gerardo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Jari
> Arkko
> Sent: Monday, February 16, 2004 11:21 AM
> To: [email-masked]
> Cc: James Kempf
> Subject: [Mip6] bootstrap problem definition
> 
> 
> 
> Hello,
> 
> James Kempf and myself wrote an initial draft on the bootstrapping
> problem in mobile ipv6. No solutions, just the problem. Comments
> appreciated. Here's the abstract:
> 
>     This document discusses the creation of a security association
>     between a mobile node and a home agent that is previously 
> unknown to
>     it.  This problem is called the bootstrapping problem.  
> The document
>     discusses several different usage scenarios, as well as related
>     issues involving informing the mobile node of changes in the home
>     network topology and mobility management service.  
> Limitations of the
>     base Mobile IPv6 protocol in dealing with the scenarios 
> are outlined.
> 
> Unfortunately, we missed the I-D deadline (or I did) so you can
> not find it from the directories. In the meantime you can access
> it from:
> 
>    http://www.arkko.com/publications/mipv6/drafts/bootstrap.txt
>    http://www.arkko.com/publications/mipv6/drafts/bootstrap.html
> 
> --Jari
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mip6
> 

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to [email-masked]. Thank you
====================================================================

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Feb 2004 22:00:45 +0200

> I read your problem statement and have some questions:

Thanks for taking the time to read it.

> 1) In section 3.2.1 you say that "...IKEv1 does not contain support for exchanging the right kind of information, primarily the NAI, with the mobile node.". Instead, rfc2407 and rfc2409 state that,…

In short, yes. Or you could send the DN from a cert, or an administrative
name associated with the preshared secret config. Or just send the home
address, and let the backend billing server sort it out...  I think the
primary issue is the ability to use the same kind of credentials that
you would use for your network access/vpn/whatever. This part in the
draft probably needs some additional work.

> 2) In section 4 it is not completely clear to me the descrition of the third scenario. What is the existing security association you are referring to? Is it the SA in place between the MN and the A…

No. Its the security association your host has a with the current access
network in order to get network access. I may be splitting hairs with the
difference between the second and the third scenario; the difference is
whether you call your operator the home network or the access network
and for what service the existing SA was intended for.

In concrete terms, in scenario 3 you could leverage your
association with your ISP, the indirect association with
the local ISP that you are roaming from, or the link layer
security association of your network connection.

--Jari