Subject: home network requested by MN may be != assigned network (was: RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02)

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 5 Mar 2007 10:16:27 +0100

Hi Kuntal, Heejin,

since the MN's MSA is the entity that assigns a home network and an MSP to the MN, I guess that it is allowed that the MSA assigns a different home network from a different MSP to the MN than requested by the MN in the Home Network Identifier DHCP Option. This is needed, e.g., when the MSA doesn't have a roaming relationship with the MSP requested by the MN, when the requested MSP doesn't provide the required service (e.g., DSMIP, NEMO etc) or when the MSA knows of a better (e.g., less loaded) home network from a different MSP. I think this is currently not mentioned in the draft and it would be good to clarify.

Regards,

Kilian

> -----Original Message-----
> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Dienstag, 27. Februar 2007 22:02
> To: [email-masked]; Kilian Weniger
> Cc: [email-masked]; Basavaraj Patil
> Subject: RE: RE: RE: [Mip6] WGLC: 
> draft-ietf-mip6-bootstrapping-integrated-02
> 
> Thanks Heejin. I think your suggested clarification # 3 is good. 
> 
> -Kuntal
> 
> 
> ________________________________________
> From: Heejin Jang [mailto:[email-masked]] 
> Sent: Sunday, February 25, 2007 8:45 PM
> To: Kilian Weniger
> Cc: [email-masked]; Basavaraj Patil
> Subject: Re: RE: RE: [Mip6] WGLC: 
> draft-ietf-mip6-bootstrapping-integrated-02
> 
> Hi, Kilian. 
> Thanks for the comments. 
>  
> Regarding the use of term, the draft(hiopt) supports all the 
> three following networks as target networks
> 1) ASP (MN's currently visited network)
> 2) Home MSP (= MSA)
> 3) MSP (network which is nether  ASP nor Home MSP but has 
> trust relationship with MN's MSA)
>  
> The term 'home MSP' can be ambiguous since it does not include 3), 
> so we will modify it to 'MSP with roaming  relationship with 
> MN's MSA' for more clarification.
> Thanks.
>  
> Regards, 
> Heejin.
> 
> ------ Original Message -------
> Sender : Kilian Weniger<[email-masked]>
> Date : 2007-02-22 23:00
> Title : RE: RE: [Mip6] WGLC: 
> draft-ietf-mip6-bootstrapping-integrated-02
> 
> Hi Heejin, 
> 
> thanks for your comments, see my replies inline.  
> 
> Please note that the comments in my mail were referring to 
> draft-ietf-mip6-bootstrapping-integrated-02. And since the reference 
> [HIOPT] in draft-ietf-mip6-bootstrapping-integrated-02 is hiopt-01, I 
> didn't consider hiopt-02.  
> 
> > -----Original Message----- 
> > From: Heejin Jang [mailto:[email-masked]]  
> > Sent: Dienstag, 20. Februar 2007 08:31 
> > To: Kilian Weniger 
> > Cc: Basavaraj Patil; [email-masked] 
> > Subject: Re: RE: [Mip6] WGLC:  
> > draft-ietf-mip6-bootstrapping-integrated-02 
> >  
> > Hi,  Kilian Weniger.  
> >  
> > Thanks for the detailedl comments.  
> >  
> > Please see the inline comments for the HIOPT draft. 
> >  
> >  
> > ------- Original Message ------- 
> > Sender : Kilian Weniger<[email-masked]> 
> > Date : 2007-02-16 17:31 
> > Title : RE: [Mip6] WGLC: 
> draft-ietf-mip6-bootstrapping-integrated-02 
> >  
> > Hi,  
> >  
> > please find below some comments about   
> > draft-ietf-mip6-bootstrapping-integrated-02.  
> >  
> > The draft is well written and easy to understand (thanks to  
> > figures and  
> > message sequence text). However, some details and corner  
> > cases are not  
> > addressed, which may need to be specified, e.g.:  
> >  
> > - How does the NAS/relay map a DHCP request received from a  
> > specific MN   
> >   to the cached home network information previously received  
> > from AAAH   
> >   for this MN, so that it can include the correct home network   
> >   information in a received DHCP request?  
> >  
> >   
> >  
> > Hiopt>> The mapping mechanism is added in section 4.3 of the  
> > latest version of the document (hiopt-02). 
> 
> It should be in section 4.2, since my question was related to 
the DHCP 
> relay behaviour. Maybe I missed it, but I can't see any 
related text in 
> section 4.2 of hiopt-02 about mapping of home information 
received from 
> AAA server to DHCP request received from MN. But Kuntal 
answered to my 
> question in his reply email.  
> 
> >  
> > The information is mapped based on NAI not by NAS but by DHCP  
> > server. Rrefer to hiopt-02 for more details. 
> >  
> >  
> > - What is the conceptual data structure needed for this in  
> > the NAS/DHCP   
> >   relay?  
> > - Any default value for how long NAS should cache home network   
> >   information received from AAA for a specific MN (i.e., 
when is NAS   
> >   allowed to delete cache entry?)? If this is specified in  
> > [MIP6-Dime]   
> >   or [MIP6-RADIUS] it should be mentioned and referenced.   
> >  
> > Hiopt>> This is implementation-specific. I'm not sure we need  
> > to describe down to the smallest detail.  
> 
> A value doesn't need to be mandated, but I think some guidance to the 
> implementor would be good. 
> 
> >  
> >  
> > - What should NAS do if DHCP request with Home network identifier   
> >   option is received from a MN and NAS doesn't find valid  
> > home network   
> >   information for this MN in its cache (e.g., since the 
cache entry   
> >   has expired)?  
> >  
> >   
> >  
> > Hiopt>>In that case, there is nothing NAS can do. If the   
> > corresponding information  
> >  
> > is configured on the DHCP server (for e.g.,  
> > pre-configuration), the server will 
> > provide it. Otherwise, it will reply with 0-lengh option. 
> 
> ok. My comment was that this should be documented (i.e., DHCP server 
> must reply with 0-lengh option in this case) 
> 
> >  
> >  
> > - What should DHCP relay/server do if the MN does not include the   
> >   OPTION_CLIENTID in the DHCP request or if 
> OPTION_MIP6-RELAY-Option   
> >   is missing in request?  
> >  
> >  
> >   
> >  
> > Hiopt>> The existing DHCP options are handled according to 
> [RFC 3315]. 
> >  
> > The request not including OPTION_CLIENTID is discarded in the  
> > relay/server 
> >  
> > as described in 15.4 of [RFC 3315].  
> 
> ok. 
> 
> >  
> >  
> > The draft may need better aligned with [HIOPT]. For instance,  
> > it is not  
> > clear to me how exactly the home network identifier option  
> > and the home   
> > network information option specified in [HIOPT] are allowed  
> > to be used  
> > in draft-ietf-mip6-bootstrapping-integrated-02:   
> >  
> > - [HIOPT] supports home address allocation. This is not 
mentioned in   
> >   draft-ietf-mip6-bootstrapping-integrated-02. Is this 
forbidden or   
> >   allowed or out-of-scope? If allowed, when does NAS set the  
> > A-flag in   
> >   the home network identifier option?  
> >  
> >   
> >  
> > Hiopt>> NAS SHOULD not modify the Home Network Identifier option.  
> > The A-flag is set to 0/1 only by the mobile node. If there is  
> > home address 
> > information at NAS that was acquired during AAA transaction,  
> > it is delivered 
> > to the DHCP server with MIP6-Relay option. (Refer hiopt-02.txt) 
> 
> I was aware of HoA allocation support in [HIOPT]. My question was 
> whether it is supported in 
> draft-ietf-mip6-bootstrapping-integrated-02 
> as well, since HoA allocation is not mentioned there. 
> 
> >  
> >  
> > - Is it allowed that multiple HA addresses are returned in 
> the home   
> >   network information option?  
> >  
> >   
> >  
> > Hiopt>> It is allowed by using multiple home network  
> > information option. 
> >  
> >   "Multiple sub-options may exist in a Home Network 
Information option 
> >  
> >    to carry more than one home information." (in section 3.3.1) 
> >  
> >  
> > - [HIOPT] allows that the home network identifier option 
> includes an   
> >   identifier of a target network, which is different from home or   
> >   visited network of MN. This is not mentioned in   
> >   draft-ietf-mip6-bootstrapping-integrated-02. Is this allowed or   
> >   forbidden?  
> >  
> >   
> >  
> > Hiopt>> A target network may or may not be home network of 
> the MN.   
> 
> good. I guess "home network" means "home MSP" in this case, right? 
> According to RFC4640, the "home MSP" is MN's MSA providing mobility 
> service to MN.  
> According to Kuntal's comment, also MSPs other than MSA (or 
"home MSP") 
> and ASP are supported as target networks. If this is true for 
hiopt (and 
> it should be if it is true for 
> draft-ietf-mip6-bootstrapping-integrated-02), then it seems that the 
> hiopt draft also uses the term "home MSP" differently than defined in 
> RFC4640. For instance, section 4.3, case C (id-type 2) says  
> 
> "In case the server cannot not find any home information neither for 
>    the local network nor for the *home MSP*, it MUST return a Home 
> Network 
>    Information option with the 0-length data." 
> 
> This would restrict HA/HoA allocation from ASP and MSA (=home MSP). I 
> guess you also want to support allocation from MSPs other 
> than ASP and 
> MSA, no? So shouldn't "home MSP" be replaced by "any other MSP with 
> roaming relationship to MN's MSA"? 
> 
> Same for id-type 1: section 3.1 says  
> 
> 
> "          id-type 
> 
>              The type of Home Network Identifier: 
> 
>                      0    Visited domain (local ASP) 
> 
>                      1    Home domain (home MSP) 
> .... 
>    Id-type 1 indicates the mobile node is interested in learning the 
>    home network information that pertains to the given realm. 
 This type 
>    can be used to discover home agents that are hosted by a 
> user's home 
>    domain (as indicated by his/her NAI-based username -- user@ 
>    HomeRealm).  The Home Network Identifier field MUST be set to the 
>    target home MSP.  " 
> 
> This text implies that HA/HoA allocation from other MSPs than 
> home MSP 
> (which is equal to MSA) is not supported with id-type 1, even 
if those 
> MSPs have a roaming relationship with the MN's MSA. Is this true?  
> 
> Regards, 
> 
> Kilian 
> 
> >  
> > In current draft, the server is supposed to provide the HA  
> > information if it has 
> >  
> > the corresponding information. If the given HA does not  
> > function as HA for 
> >  
> > the requesting MN, it will reply with the BA status = 132 or 133   
> >  
> > (Not home subnet / home agent for this mobile node) during  
> > MN's registration. 
> >  
> >  
> > - Which HA information should the MN use if it receives,  
> > e.g., an FQDN   
> >   and a HA address in DHCP reply? [HIOPT] refers to section 
> 3.6 of   
> >   draft-ietf-mip6-bootstrapping-integrated-01, but this  
> > section doesn't  
> >   exist in draft-ietf-mip6-bootstrapping-integrated-02 anymore...  
> >  
> >  
> >   
> >  
> > Hiopt>> It is within the MN's own discretion as follows.  
> >  
> > I don't think it should be standardized in HIOPT document.  
> >  
> > "For example, if the mobile node acquires both IPv6  
> > address(es) and FQDN(s) 
> >  of the home agents, it may try to use the address  
> > information of the home agent(s) first." 
> >  
> >   
> >  
> >  
> > Some other comments:  
> >  
> > - It would be good to have a section, which explicitly states   
> >   assumptions and applicability of the protocol. This 
should include:  
> >     - MSA and ASA must be co-located (i.e., integrated scenario)  
> >     - AAA infrastructure assumed and some kind of roaming   
> >         relationship between ASP and MSA/ASA is required  
> >     - MSP is either co-located with ASP or MSA or both  
> >         (Or are other target networks allowed; see above)?  
> >     - DHCP relay and NAS must be co-located  
> >  
> > - At some places in the text the use of the term "MSP" is 
> ambiguous,   
> >   since MSP can refer to at least home and visited network. 
Better   
> >   use "home MSP" for MSP in home network.  
> >     - e.g., section 3.1:  
> >   "Note that a home agent for usage  
> >    with the mobile node might be selected in the access service  
> >    provider's network or alternatively in the *home* 
> mobility service  
> >    provider's network."  
> >     - or in section 3.2:  
> >   "The message flows for home agent  
> >    allocation in the ASP and the *home* MSP are illustrated 
> below.    
> >     - or in section 3.2.1:  
> >   "3.2.1.  Home Agent allocation in the *home* MSP",  
> >   "(4)... mobile node is requesting home agent information in the   
> >   *home* MSP..."  
> >  
> > - Section 3.3 currently mentions DNS-based HA address  
> > discovery method  
> >   only, but [BOOT-SPLIT] also specifies an anycast-based HA 
address   
> >   discovery method. Either both or none should be mentioned.  
> >  
> > - The title of draft-ietf-mip6-bootstrapping-integrated-02 
can cause   
> >   the impression that the draft defines a complete bootstrapping    
> >   procedure. But draft-ietf-mip6-bootstrapping-integrated-02  
> > defines a   
> >   method for HA address assignment only. I think this is 
misleading.   
> >   Why not name the draft according to what it specifies 
> (e.g., "HA   
> >   address assignment using DHCP and AAA" or "HA address  
> > assignment for   
> >   the integrated scenario using DHCP and AAA" instead of   
> >   "MIP6-bootstrapping for the integrated scenario")?  
> >  
> > Regards,  
> >  
> > Kilian  
> >  
> > > -----Original Message-----  
> > > From: Basavaraj Patil [mailto:[email-masked]]   
> > > Sent: Mittwoch, 14. Februar 2007 19:10  
> > > To: [email-masked]  
> > > Subject: [Mip6] WGLC: 
> draft-ietf-mip6-bootstrapping-integrated-02  
> > >   
> > >   
> > > Hello,  
> > >   
> > > This is a MIP6 Working group last call for the WG I-D:  
> > > "MIP6-bootstrapping for the Integrated Scenario",  
> > > draft-ietf-mip6-bootstrapping-integrated-02.txt  
> > >   
> > > I-D:   
> > > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-  
> > > integrated-dhc  
> > > -02.txt  
> > >   
> > > Please review and submit your comments to the authors or  
> > the mailing  
> > > list. The WGLC will expire on March 1st, 07.  
> > >   
> > > -Chairs  
> > >   
> > >   
> > > _______________________________________________  
> > > Mip6 mailing list  
> > > [email-masked]  
> > > https://www1.ietf.org/mailman/listinfo/mip6  
> > >   
> > >   
> >  
> >  
> > Panasonic R&D Center Germany GmbH  
> > 63225 Langen, Hessen, Germany  
> > Reg: AG Offenbach (Hessen) HRB 33974  
> > Managing Director: Thomas Micke  
> >  
> >  
> >  
> > _______________________________________________  
> > Mip6 mailing list  
> > [email-masked]  
> > https://www1.ietf.org/mailman/listinfo/mip6  
> >  
> >  
> >  
> >  
> >  
> 
> 
> Panasonic R&D Center Germany GmbH 
> 63225 Langen, Hessen, Germany 
> Reg: AG Offenbach (Hessen) HRB 33974 
> Managing Director: Thomas Micke 
> 
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

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

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Mon, 5 Mar 2007 11:17:12 -0500

Hi Kilian,

If the MSA assigns Home Agent info in domain X which is MN's home MSP and the MN requests for Home Agent info for domain Y (another MSP), the DHCP server may not have that info. In that case, it returns a local Home Agent. I think this is mentioned in HIOPT I-D:

"
Id-type 1 indicates the mobile node is interested in learning the
   home network information that pertains to the given realm.  This type
   can be used to discover home agents that are hosted by a user's home
   domain (as indicated by his/her NAI-based username -- user@
   HomeRealm).  The Home Network Identifier field MUST be set to the
   target home MSP.  In case there is no available home information for
   the specified home MSP in the DHCP server, the local home information
   is provided.
"

We can clarify this in the integrated I-D as you suggested.

Thanks for your comments.

-Kuntal

> From: Kilian Weniger [mailto:[email-masked]]
> Sent: Monday, March 05, 2007 3:16 AM
> To: Chowdhury, Kuntal
> Cc: [email-masked]; Mobile IPv6 Mailing List
> Subject: home network requested by MN may be != assigned network (was: RE:
> [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02)
> 
> Hi Kuntal, Heejin,
> 
> since the MN's MSA is the entity that assigns a home network and an MSP to
> the MN, I guess that it is allowed that the MSA assigns a different home
> network from a different MSP to the MN than requested by the MN in the
> Home Network Identifier DHCP Option. This is needed, e.g., when the MSA
> doesn't have a roaming relationship with the MSP requested by the MN, when
> the requested MSP doesn't provide the required service (e.g., DSMIP, NEMO
> etc) or when the MSA knows of a better (e.g., less loaded) home network
> from a different MSP. I think this is currently not mentioned in the draft
> and it would be good to clarify.
> 
> Regards,
> 
> Kilian
> 
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 6 Mar 2007 16:48:34 +0100

Hi Kuntal,

thanks for the clarification, but it is still not clear to me how assignment of HA information pertaining to an MSP X different from ASP and Home MSP Y (that has trust relationship with MN's MSA) works. Heejin and you said that in an earlier mail that this is supported, but I can't find any details in the drafts. 

Is the MSA allowed to send HA information to the NAS during network authentication, which pertains to an MSP X different from the MN's home MSP Y, so that the NAS/DHCP would associate the received information with the home MSP domain Y? The NAS/DHCP would then return home information pertaining to MSP X to the MN, even though the target network requested by the MN was (home) MSP Y.

Or is such assignment only possible if the MN requests a target network MSP X, which is neither ASP nor Home MSP Y? Since the MSA doesn't know the target network requested by the MN at the time of network authentication, would the MSA always send to the NAS during network authentication multiple HAs pertaining to all MSPs that the MN is allowed to use and the DHCP server picks the correct one according to the requested target network? 

Thanks,

Kilian

> Sent: Montag, 5. März 2007 17:17
> To: Kilian Weniger
> Subject: RE: home network requested by MN may be != assigned 
> network (was: RE: [Mip6] WGLC: 
> draft-ietf-mip6-bootstrapping-integrated-02)
> 
> Hi Kilian,
> 
> If the MSA assigns Home Agent info in domain X which is MN's 
> home MSP and the MN requests for Home Agent info for domain Y 
> (another MSP), the DHCP server may not have that info. In 
> that case, it returns a local Home Agent. I think this is 
> mentioned in HIOPT I-D:
> 
> "
> allowed or
> > > > > From: Basavaraj Patil [mailto:[email-masked]]
> > > > > Sent: Mittwoch, 14. Februar 2007 19:10
> > > > > To: [email-masked]
> > > > > Subject: [Mip6] WGLC:
> > > > > Hello,
> > > > > This is a MIP6 Working group last call for the WG I-D:
> > > > > "MIP6-bootstrapping for the Integrated Scenario",
> > > > > draft-ietf-mip6-bootstrapping-integrated-02.txt
> > > > >
> > > > > I-D:
> > > > > http://ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-
> > > > > integrated-dhc
> > > > > -02.txt
> > > > >
> > > > > Please review and submit your comments to the authors or
> > > > the mailing
> > > > > list. The WGLC will expire on March 1st, 07.
> > > > >
> > > > > -Chairs
> > > > >
> > > > >
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
> 
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 13 Mar 2007 23:50:15 -0400

Hi Kilian,

Sorry for the late follow-up. Please see my reply inline...

-Kuntal

> Sent: Tuesday, March 06, 2007 9:49 AM
> To: Chowdhury, Kuntal
> Cc: Mobile IPv6 Mailing List; [email-masked]
> Subject: RE: home network requested by MN may be != assigned network (was:
> RE: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-integrated-02)
> 
> Hi Kuntal,
> 
> thanks for the clarification, but it is still not clear to me how
> assignment of HA information pertaining to an MSP X different from ASP and
> Home MSP Y (that has trust relationship with MN's MSA) works. Heejin and
> you said that in an earlier mail that this is supported, but I can't find
> any details in the drafts.
> 
[KC>] the information of all the home agents assigned in the MSPs (home or not) will come in AAA attributes. Each assigned home agent address will have an associated FQDN in the AAA attributes. The DHCP server stores this info and sends the home agent information that matches the FQDN in the home network information field in the DHCP request to the FQDN stored (received from AAA).

> Is the MSA allowed to send HA information to the NAS during network
> authentication, which pertains to an MSP X different from the MN's home
> MSP Y, so that the NAS/DHCP would associate the received information with
> the home MSP domain Y? The NAS/DHCP would then return home information
> pertaining to MSP X to the MN, even though the target network requested by
> the MN was (home) MSP Y.
>
[KC>] No, if the MN requested home info for target network X, the DHCP server should not return home info for target network Y. I think HIOPT says that in such case, the DHCP server may return home info for the local network in case the MN can utilize the services of a local home agent.

> Or is such assignment only possible if the MN requests a target network
> MSP X, which is neither ASP nor Home MSP Y? Since the MSA doesn't know the
> target network requested by the MN at the time of network authentication,
> would the MSA always send to the NAS during network authentication
> multiple HAs pertaining to all MSPs that the MN is allowed to use and the
> DHCP server picks the correct one according to the requested target
> network?
> 
[KC>] Yes, the MSA does not know a priori which target network's home info the MN is going to request. That's why the MSA (AAA server) sends all the authorized target network info to the NAS at the time of access auth.

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 14 Mar 2007 10:11:22 +0100

Hi Kuntal,

<snip>
> [KC>] Yes, the MSA does not know a priori which target 
> network's home info the MN is going to request. That's why 
> the MSA (AAA server) sends all the authorized target network 
> info to the NAS at the time of access auth.
<snip>

ok, this should work. Some more text about this would be good to have in
the next version of the draft. 

However, I'm not sure if the current version of
draft-ietf-dime-mip6-integrated supports sending more than one MIPv6
bootstrapping AVP of the same type (e.g., MIP6-Home-Agent-FQDN) from
AAAH to NAS. It might require a slight update to clarify that this is
supported.

Regards,

Kilian