Re: [Mip6] Bootstrapping DT solution draft

[Rafa Marin Lopez <[e-mail]>]

Hi Gerardo

Sorry for my delayed answer. Please see my comments inline:

>>$Rafa> I was wondering what is the role of MSP AAA server in 
>>the roaming
>>scenario. For example considering following example:
>>
>>MN <---------IKEv2(EAP)------------>HA<------Diameter(EAP) ------->
>>MSA's AAA server
>>
>>HA can request a redirect agent to contact directly with MSA's AAA
>>server (at least this policy is being followed with network 
>>access service
>>as far as I know). So what is the role of MSP's AAA server?? only AAA
>>routing??
>>
>>    
>>
>AAA server is involved in AAA routing. But, as you mention below, it
>should have an active role also in the authorization step, since the
>usage of the HA in the MSP may need to be explicetly authorized by the
>MSP itself. 
>  
>
<$Rafa> Then maybe it should be reflected in the I-D

>  
>
>>Another related question is about authorization. Under my 
>>point of view
>>, MSP's AAA server is the entity that finally takes decision about if
>>the mobility service is authorized or not. MSA's AAA server could send
>>to MSP's AAA some kind of evidences or attributes related with
>>authenticated user.Following these attributes and internal policies
>>MSP's AAA server takes a final decision.
>>
>>    
>>
>
>I tend to agree. This is the reason why AAA server of the MSP should be
>involved. I think that these issues should be covered by
>draft-mip6-aaa-ha-goals.
>
<$rafa> Well... in the MIP6 bootstrapping draft , you mention that MSA 
is giving authorization.
However if you agree that MSP can be involved in the authorization , I 
don't see why it should explained
in draft-mip6-aaa-ha-goals.

> As you know, in this DT draft, we have not
>spcified the backend communitcation between HA and AAA infrastructure
>since we consider it out of the scope of the DT.
>  
>
<$Rafa> Yes I know

>  
>
>>In particular , I was thinking a similar model than it is shown in
>>Diameter EAP application I-D (Scenario 3: Direct EAP, 
>>authorization via
>>agents).
>>
>>Note this dicussion could be also valid for other services 
>>(i.e. network
>>access service).
>>
>>    
>>
>
>I tend to agree also here. The MSP might need to add some authorization
>AVPs. 
>
<$Rafa> I agree that AVPs or specific information could be placed on 
draf-ietf-aaa-ha-goals but to say if MSP is involved in authorization or not
could be said in bootstrapping solution I-D.

>But, again, I think this is out of the scope of this draft. These
>issues will be considered when we'll discuss the AAA backend protocol
>specification.
>
>
>  
>
>>>Therefore, in the split scenario, two different cases can be 
>>>identified depending on the relationship between the entity that 
>>>provides the mobility service (i.e. Mobility Service Provider, MSP) 
>>>and the entity that authenticates and authorizes the user (i.e. 
>>>Mobility Service Authorizer, MSA).
>>>Figure 1 depicts the split scenario when the MSP and the 
>>>      
>>>
>>MSA are the 
>>    
>>
>>>same entity. This means that the network operator that provides the 
>>>Home Agent authenticates and authorizes the user for 
>>>      
>>>
>>mobility service.
>>
>>
>>$Rafa> During text, you also consider PKI as backend infrastructure.
>>Maybe it should appear in the figure 1 not only AAA.
>>
>>    
>>
>
>Yes, you are right. I'll add it as a possible choice.
>  
>
<$rafa> Ok

>  
>
>>>Mobility Service Provider and Authorizer 
>>>+-------------------------------------------+ | | | +-------------+ 
>>>+--+ | | | MSA/MSP AAA | <-------------> |HA| | | | server | AAA 
>>>protocol +--+ | | +-------------+ | | | 
>>>+-------------------------------------------+ +--+ |MN| 
>>>      
>>>
>>+--+ Figure 1 
>>    
>>
>>>- Split Scenario (MSA == MSP) G. Giaretta, Ed. Expires December 22, 
>>>2005 [Page 6]
>>>
>>>
>>>
>>>
>>>      
>>>
>><snip>
>>
>>    
>>
>>>4. Components of the solution
>>>The bootstrapping problem is composed of different 
>>>      
>>>
>>sub-problems that 
>>    
>>
>>>can be solved independently in a modular way. The components 
>>>identified and a brief overview of their solution follow.
>>>o HA address discovery. The Mobile Node needs to discover 
>>>      
>>>
>>the address 
>>    
>>
>>>of its Home Agent. The main objective of a bootstrapping 
>>>      
>>>
>>solution is 
>>    
>>
>>>to minimize the data pre-configured on the Mobile Node. For this 
>>>reason, the DHAAD defined in [2] may not be applicable in real 
>>>deployments since it is required that the Mobile Node is 
>>>pre-configured with the home network prefix and it does not 
>>>      
>>>
>>allow an 
>>    
>>
>>>operator to load balance by having Mobile Nodes dynamically 
>>>      
>>>
>>assigned 
>>    
>>
>>>to Home Agents located in different subnets. This document 
>>>      
>>>
>>defines a 
>>    
>>
>>>solution for Home Agent address discovery that is based on 
>>>      
>>>
>>Domain Name 
>>    
>>
>>>Service (DNS), introducing a new DNS SRV record [5].
>>>
>>>The unique information that needs to be pre-
>>>configured on the Mobile Node is the domain name of the MSP.
>>>
>>>      
>>>
>><snip>
>>
>>    
>>
>>>o IPsec Security Associations setup. MIPv6 requires that a 
>>>      
>>>
>>Mobile Node 
>>    
>>
>>>and its Home Agent share an IPsec SA in order to protect binding 
>>>updates and other MIPv6 signaling. This document provides a 
>>>      
>>>
>>solution 
>>    
>>
>>>that is based on IKEv2 and follows what is specified in 
>>>      
>>>
>>[6]. The IKEv2 
>>    
>>
>>>peer authentication can be performed both using 
>>>      
>>>
>>certificates and using 
>>    
>>
>>>EAP, depending on the network operator's deployment model.
>>>o HoA assignment. The Mobile Node needs to know its Home Address in 
>>>order to bootstrap Mobile IPv6 operation. The Home Address 
>>>      
>>>
>>is assigned 
>>    
>>
>>>by the Home Agent during the IKEv2 exchange (as described 
>>>      
>>>
>>in [6]). The 
>>    
>>
>>>solution defined in this draft also allows the Mobile Node to 
>>>auto-configure its Home Address based on stateless auto-
>>>configuration ([20]), Cryptographically Generated Addresses 
>>>      
>>>
>>([9]) or 
>>    
>>
>>>privacy addresses ([10]).
>>>o Authentication and Authorization with MSA. The user must be 
>>>authenticated in order for the MSA to grant the service.
>>>      
>>>
>><$Rafa> Here appears "MSA to grant the service" and in page 
>>10 section 
>>5.1.1
>>"MSP granting the mobility service". Would it not be in the first case
>>"MSP to grant the service" too?
>>
>>    
>>
>
>Yes. What about the following text?
>
>"
>Authentication and Authorization with MSA. The user must be
>authenticated in order for the MSP to grant the service. Since the user
>credentials can be verified only by the MSA, this authorization step is
>performed by the MSA. Moreover, the mobility service must be explicitly
>authorized by the MSA based on the user's profile. These operations are
>performed in different ways depending on the credentials used by the
>Mobile Node during the IKEv2 peer authentication and on the backend
>infrastructure (PKI or AAA). 
>  
>
>"
>  
>
<$Rafa> As you can see, this text still state MSA is explicitly doing 
the authorization and MSP is not involved.
So I understand from this that MSP's AAA server is only doing routing.

>
>  
>
>><snip>
>>
>>    
>>
>>>5. Protocol Operations
>>>This section describes in detail the procedures needed to perform 
>>>Mobile IPv6 bootstrapping based on the components identified in the 
>>>previous section.
>>>
>>>5.1. Home Agent Address Discovery
>>>Once a Mobile Node has obtained network access, it can 
>>>      
>>>
>>perform Mobile 
>>    
>>
>>>IPv6 bootstrapping. For this purpose, the Mobile Node 
>>>      
>>>
>>queries the DNS 
>>    
>>
>>>server to request information on Home Agent service. As mentioned 
>>>before in the document, the only information that needs to be auto-
>>>configured
>>>      
>>>
>><$Rafa> autoconfigured---> pre-configured??
>>
>>    
>>
>
>fixed.
>  
>
<$rafa> ok.

>  
>
>>>on the Mobile Node is the domain name of the Mobility 
>>>      
>>>
>>Service Provider.
>>    
>>
>>>The Mobile Node needs to obtain the IP address of the DNS server 
>>>before it can send a DNS request. This can be pre-configured on the 
>>>Mobile Node or obtained through DHCPv6 from the visited 
>>>      
>>>
>>link [11]. In 
>>    
>>
>>>any case, it is assumed that there is some kind of 
>>>      
>>>
>>mechanism by which 
>>    
>>
>>>the Mobile Node is configured with a DNS server since a DNS 
>>>      
>>>
>>server is 
>>    
>>
>>>needed for many other reasons.
>>>Two options for DNS lookup for a Home Agent address are 
>>>      
>>>
>>identified in 
>>    
>>
>>>this document: DNS lookup by Home Agent Name and DNS lookup 
>>>      
>>>
>>by service 
>>    
>>
>>>name.
>>>While this document specifies a Home Agent Address 
>>>      
>>>
>>Discovery solution 
>>    
>>
>>>based on DNS, when the ASP and the MSP are the same entity 
>>>      
>>>
>>DHCP may be 
>>    
>>
>>>used. See [15] for details.
>>>
>>>      
>>>
>><snip>
>>
>>    
>>
>>>5.4. Authorization and Authentication with MSA
>>>In a scenario where the Home Agent is discovered dynamically by the 
>>>Mobile Node, it is very likely that the Home Agent is not able to 
>>>verify by its own the credentials provided by the Mobile 
>>>      
>>>
>>Node during 
>>    
>>
>>>the IKEv2 exchange. Moreover, the mobility service needs to be 
>>>explicitly authorized based on the user's profile.
>>>      
>>>
>>
>>    
>>
>>>As an example, the Home Agent might not be aware if the mobility 
>>>service can be granted at a particular time of the day or if the 
>>>credit of the Mobile Node is going to expire.
>>>
>>>      
>>>
>><$Rafa> In the example, could MSA know that mobility service can be or
>>cannot be granted at a particular time depending on internal 
>>policies in
>>the MSP? I guess this example considers that user's profile says that
>>this user cannot use the service during a particular time of the
>>day.However it does not consider that user has no restricction about
>>this time but MSP decides that mobility service cannot be 
>>granted during
>>a particular time of the day. Home Agent should be aware of this too.
>>
>>    
>>
>
>Yes. The text refers to policies that the MSA might send to the MSP
>based on the user's profile. However, as you mention, some policies can
>be also forced by the MSP. Do you think we need some text about that in
>the draft? 
>  
>
<$rafa> As I mentioned previosly, i think some text about MSP and MSP's 
AAA server role should be included. Although I don't know what others 
think. However I recognize the same text could be applied for other 
services not only MIP6

>  
>
>>>Due to all these reasons, the Home Agent may need to 
>>>      
>>>
>>contact the MSA 
>>    
>>
>>>in order to authenticate
>>>
>>>the Mobile Node and authorize mobility G. Giaretta, Ed. Expires 
>>>December 22, 2005 [Page 14]
>>>
>>>
>>>
>>>
>>>
>>>
>>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005
>>>service. This can be accomplished based on a Public Key 
>>>      
>>>
>>Infrastructure 
>>    
>>
>>>if certificates are used and a PKI
>>>
>>>      
>>>
>><$Rafa> For authorization ... are you considering attributes 
>>certificates when
>>PKI is used...??
>>
>>    
>>
>
>How to use PKI for authorization purposes is actually a general open
>issue, not only in this draft. We mentioned this in the draft but I
>think this is more in the scoper of AAA-HA interface solution. Maybe
>Hannes could be more precise about that since he had some ideas during
>DT discussion.
>  
>
<%Rafa> waiting for Hannes' answer.

>  
>
>>>is deployed by the MSP and MSA. On the other hand, if the 
>>>      
>>>
>>Mobile Node 
>>    
>>
>>>is provided with other types of credentials, the AAA infrastructure 
>>>must be used.
>>>The definition of this backend communication is out of the scope of 
>>>this document. In [12] a list of goals for such a communication is 
>>>provided.
>>>
>>>
>>>6. Home Address registration in the DNS
>>>In order that the Mobile Node is reachable through its dynamically 
>>>assigned Home Address, the DNS needs to be updated with the 
>>>      
>>>
>>new Home 
>>    
>>
>>>Address. Since applications make use of DNS lookups on FQDN 
>>>      
>>>
>>to find a 
>>    
>>
>>>node, the DNS update is essential for providing IP 
>>>      
>>>
>>reachability to the 
>>    
>>
>>>Mobile Node, which is the main purpose of the Mobile IPv6 protocol. 
>>>The need of DNS update is not discussed in RFC 3775 since 
>>>      
>>>
>>it assumes 
>>    
>>
>>>that the Mobile Node is provisioned with a static home address. 
>>>However, when a dynamic Home Address is assigned to the 
>>>      
>>>
>>Mobile Node, 
>>    
>>
>>>any existing DNS entry becomes invalid and the Mobile Node becomes 
>>>unreachable unless a DNS update is performed.
>>>Since the DNS update must be performed securely in order to prevent 
>>>attacks or modifications from malicious nodes, the node performing 
>>>this update must share a security association with the DNS server. 
>>>Having all possible Mobile Nodes sharing a security 
>>>      
>>>
>>association with 
>>    
>>
>>>the DNS servers of the MSP might be cumbersome from an 
>>>      
>>>
>>administrative 
>>    
>>
>>>perspective. Moreover, even if a Mobile Node has a security 
>>>association with a DNS server of its MSP, an address authorization 
>>>issue comes into the picture. A detailed analysis of 
>>>      
>>>
>>possible threats 
>>    
>>
>>>against DNS update is provided in section 9.5.
>>>Therefore, due to security and administrative reasons, it is 
>>>RECOMMENDED that the Home Agent perform DNS entry update for the 
>>>Mobile Node. For this purpose the Mobile Node MAY include a new 
>>>mobility option, the DNS Update option, with the flag R not 
>>>      
>>>
>>set in the 
>>    
>>
>>>Binding Update. This option is defined in section 8 and 
>>>      
>>>
>>includes the 
>>    
>>
>>>FQDN that needs to be updated. After receiving the Binding 
>>>      
>>>
>>Update, the 
>>    
>>
>>>Home Agent MUST update the DNS entry with the identifier 
>>>      
>>>
>>provided by 
>>    
>>
>>>the Mobile Node and the Home Address included in the Home Address 
>>>Option. The procedure for sending a dynamic DNS update message is 
>>>specified in [14]. The dynamic DNS update SHOULD be performed in a 
>>>secure way; for this reason, the usage of TKEY and TSEC or 
>>>      
>>>
>>DNSSEC is 
>>    
>>
>>>recommended (see section 9.5 for details). As soon as the 
>>>      
>>>
>>Home Agent 
>>    
>>
>>>has updated the DNS, it MUST send a Binding Acknowledgement 
>>>      
>>>
>>message to 
>>    
>>
>>>the Mobile Node including the DNS Update mobility option with the 
>>>correct value in the Status field (see section 8.1).
>>>This procedure can be performed directly by the Home Agent 
>>>      
>>>
>>if the Home 
>>    
>>
>>>Agent has a security association with the domain specified in the 
>>>Mobile Node's FQDN.
>>>
>>>
>>>      
>>>
>><$Rafa> Why don't MSP's AAA server could do DNS update 
>>instead of MSA's
>>AAA server??
>>
>>    
>>
>
>It could. But I don't see a reason for that. Do you see any issue with
>the current solution? 
>  
>
<%Rafa> if MSP provides the Home Agent , and Home Agent gives a Home 
Address... would not be more coherent that MSP's AAA server did this task?

>  
>
>>>On the other hand, if the Mobile Node wants to be reachable 
>>>      
>>>
>>through a 
>>    
>>
>>>FQDN that belongs to the MSA, the Home Agent and the DNS 
>>>      
>>>
>>server that 
>>    
>>
>>>must be updated belong to different administrative domain. 
>>>      
>>>
>>In this G. 
>>    
>>
>>>Giaretta, Ed. Expires December 22, 2005 [Page 16]
>>>
>>>
>>>
>>>
>>>
>>>
>>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005
>>>case the Home Agent may not share a security association 
>>>      
>>>
>>with the DNS 
>>    
>>
>>>server and the DNS entry update can be performed by the AAA 
>>>      
>>>
>>server of 
>>    
>>
>>>the MSA. In order to accomplish this, the Home Agent sends 
>>>      
>>>
>>to the AAA 
>>    
>>
>>>server the FQDN-HoA pair through the AAA protocol. This message is 
>>>proxied by the AAA infrastructure of the MSP and is received by the 
>>>AAA server of the MSA. The AAA server of the MSA perform the DNS 
>>>update based on [14]. The detailed description of the communication 
>>>between Home Agent and AAA is out of the scope of this draft. More 
>>>details are provided in [12].
>>>
>>>
>>>      
>>>
>><snip>
>>
>>    
>>
>>>9. Security Considerations
>>>9.1. HA Address Discovery
>>>Use of DNS for address discovery carries certain security 
>>>      
>>>
>>risks. DNS 
>>    
>>
>>>transactions in the Internet are typically done without any 
>>>authentication of the DNS server by the client or of the 
>>>      
>>>
>>client by the 
>>    
>>
>>>server. There are two risks involved:
>>>1) A legitimate client obtains a bogus Home Agent address 
>>>      
>>>
>>from a bogus 
>>    
>>
>>>DNS server. This is sometimes called a "pharming" attack,
>>>2) An attacking client obtains a legitimate Home Agent 
>>>      
>>>
>>address from a 
>>    
>>
>>>legitimate server.
>>>
>>>      
>>>
>><$Rafa>I have a comment regarding this case 1): I think any 
>>user already
>>authenticated and authorized to use mobility service could launch
>>this attack becuase user already owns a valid certificate and 
>>therefore
>>a legitimate client could verify this certificate. The issue is this
>>user is NOT AUTHORIZED to be a Home Agent. what do you think??
>>
>>    
>>
>
>I don't get your point. Which scenario are you referring to? Are you
>assuming only certificates is used or also AAA?
>  
>
<$Rafa> I am assuming only certificates.


>  
>
>>>The risk in Case 1 is mitigated because the Mobile Node is 
>>>      
>>>
>>required to 
>>    
>>
>>>conduct an IKE transaction with the Home Agent prior to 
>>>      
>>>
>>performing a 
>>    
>>
>>>Binding Update to establish Mobile IPv6 service. According to the 
>>>IKEv2 specification [7], the responder must present the 
>>>      
>>>
>>initiator with 
>>    
>>
>>>a valid certificate containing the responder's public key, and the 
>>>responder to initiator IKE_AUTH message must be protected with an 
>>>authenticator calculated using the public key in the certificate. 
>>>Thus, an attacker would have to set up both a bogus DNS 
>>>      
>>>
>>server and a 
>>    
>>
>>>bogus Home Agent, and provision the Home Agent with a 
>>>      
>>>
>>certificate that 
>>    
>>
>>>a victim Mobile Node could verify. If the Mobile Node can 
>>>      
>>>
>>detect that 
>>    
>>
>>>the certificate is not trustworthy, the attack will be 
>>>      
>>>
>>foiled when the 
>>    
>>
>>>Mobile Node attempts to set up the IKE SA.
>>>
>>>
>>>      
>>>
>><snip>
>>
>>    
>>
>>>9.5. Dynamic DNS Update
>>>Mobile IPv6 bootstrapping recommends the Home Agent to update the 
>>>Mobile Node's FQDN with a dynamically assigned home address rather 
>>>than have the Mobile Node itself do it (see Section 6 above). This 
>>>choice was motivated by a concern for preventing redirection-based 
>>>flooding attacks (see draft-ietf-mip6-ro-sec [19] for more 
>>>      
>>>
>>information 
>>    
>>
>>>about redirection-based flooding attacks and the role 
>>>      
>>>
>>preventing them 
>>    
>>
>>>played in the design of Mobile IPv6 route optimization security). 
>>>Exactly as for route optimization, it is possible for a 
>>>      
>>>
>>node that is 
>>    
>>
>>>the legitimate owner of a DNS FQDN - in the sense that it has a 
>>>security association with the DNS server allowing it to perform 
>>>dynamic DNS update of its FQDN - to bind its FQDN to the 
>>>      
>>>
>>address of a 
>>    
>>
>>>victim, then redirect large volumes of traffic at the victim. The 
>>>attack may be propagated without the owner's knowledge, for 
>>>      
>>>
>>example, 
>>    
>>
>>>if the node is compromised by malware, or it may be 
>>>      
>>>
>>intentional if the 
>>    
>>
>>>node itself is the attacker.
>>>While it is possible to prevent redirection attacks through ingress 
>>>filtering on access routers, ISPs have little or no incentive to 
>>>deploy ingress filtering. In some cases, if an attack could 
>>>      
>>>
>>result in 
>>    
>>
>>>substantial financial gain, it is even possible that a 
>>>      
>>>
>>corrupt ISP may 
>>    
>>
>>>have an incentive not to deploy ingress filters such as has 
>>>      
>>>
>>been the 
>>    
>>
>>>case for spam. Consequently, the security for dynamic 
>>>      
>>>
>>Mobile Node FQDN 
>>    
>>
>>>update has been assigned to the Home Agent, where active network 
>>>administration and vigilant defense measures are more 
>>>      
>>>
>>likely to (but 
>>    
>>
>>>G. Giaretta, Ed. Expires December 22, 2005 [Page 25]
>>>
>>>
>>>
>>>
>>>
>>>
>>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005
>>>are not assured of) mitigating problems, and the owner of 
>>>      
>>>
>>the Mobile 
>>    
>>
>>>Node is more likely to detect a problem if it occurs.
>>>If a Home Agent performs dynamic DNS update on behalf of the Mobile 
>>>Node directly with the DNS server, the Home Agent MUST have 
>>>      
>>>
>>a security 
>>    
>>
>>>association of some type with the DNS server. The security 
>>>      
>>>
>>association 
>>    
>>
>>>MAY be established either using DNSSEC [16] or TSIG/TKEY 
>>>      
>>>
>>[17][18]. A 
>>    
>>
>>>security association is required even if the DNS server is 
>>>      
>>>
>>in the same 
>>    
>>
>>>administrative domain as the Home Agent. The security association 
>>>SHOULD be separate from the security associations used for other 
>>>purposes, such as AAA.
>>>In the case where the Mobility Service Provider is 
>>>      
>>>
>>different from the 
>>    
>>
>>>Mobility Service Authorizer, the network administrators may want to 
>>>limit the number of cross-administrative domain security 
>>>      
>>>
>>associations. 
>>    
>>
>>>If the Mobile Node's FQDN is in the Mobility Service Authorizer's 
>>>domain, since a security association for AAA signaling involved in 
>>>mobility service authorization is required in any case, the 
>>>      
>>>
>>Home Agent 
>>    
>>
>>>can send the Mobile Node's FQDN to the AAA server under the HA-AAA 
>>>server security association,
>>>      
>>>
>>$Rafa> MSA's AAA Server?? or MSP's AAA server??
>>
>>    
>>
>
>To the MSA's AAA server through the MSP's AAA server. The MSA's AAA
>server updates the MSA's DNS server. 
>
>  
>
>>So far, these are my comments.
>>
>>    
>>
>
>Thanks again,
>
>--Gerardo
>
>  
>
>>Regards.
>>
>>-- 
>>------------------------------------------------------
>>Rafael Marin Lopez
>>Faculty of Computer Science-University of Murcia
>>30071 Murcia - Spain
>>Telf: [phone] e-mail: [e-mail]
>>------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
>>
>>Gerardo Giaretta wrote:
>>
>>    
>>
>>>Dear WG,
>>>
>>>the bootstrapping DT has submitted a solution draft. The document
>>>defines how a Mobile Node can bootstrap MIPv6 operations from
>>>non-topological information and pre-configured security 
>>>      
>>>
>>credentials. The
>>    
>>
>>>solution solves the boostrapping problem when the Mobile 
>>>      
>>>
>>Node's mobility
>>    
>>
>>>service is authorized by a different service provider than 
>>>      
>>>
>>basic network
>>    
>>
>>>access (i.e. split scenario).
>>>
>>>The draft can be found at
>>>
>>>      
>>>
>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp
>>ing-split-
>>    
>>
>>>00.txt.
>>>
>>>The DT is currently working on optimized solutions for integrated
>>>scenario (i.e. mobility service and basic network access 
>>>      
>>>
>>are authorized
>>    
>>
>>>by the same entity).
>>>
>>>Please read the document and provide comments.
>>>
>>>Thanks and regards,
>>>
>>>--Gerardo (DT editor)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia 
>>>S.p.A.
>>>
>>>====================================================================
>>>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 send an e_mail to
>>>[e-mail]. Thank you
>>>====================================================================
>>>
>>>_______________________________________________
>>>Mip6 mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/mip6
>>>
>>>
>>>
>>>
>>>      
>>>
>>
>>
>>Gerardo Giaretta wrote:
>>
>>    
>>
>>>Dear WG,
>>>
>>>the bootstrapping DT has submitted a solution draft. The document
>>>defines how a Mobile Node can bootstrap MIPv6 operations from
>>>non-topological information and pre-configured security 
>>>      
>>>
>>credentials. The
>>    
>>
>>>solution solves the boostrapping problem when the Mobile 
>>>      
>>>
>>Node's mobility
>>    
>>
>>>service is authorized by a different service provider than 
>>>      
>>>
>>basic network
>>    
>>
>>>access (i.e. split scenario).
>>>
>>>The draft can be found at
>>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap
>>>      
>>>
>>ping-split-
>>    
>>
>>>00.txt.
>>>
>>>The DT is currently working on optimized solutions for integrated
>>>scenario (i.e. mobility service and basic network access are 
>>>      
>>>
>>authorized
>>    
>>
>>>by the same entity).
>>>
>>>Please read the document and provide comments.
>>>
>>>Thanks and regards,
>>>
>>>--Gerardo (DT editor)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>Gruppo Telecom Italia - Direzione e coordinamento di Telecom 
>>>      
>>>
>>Italia S.p.A.
>>    
>>
>>>====================================================================
>>>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 send an e_mail to
>>>[e-mail]. Thank you
>>>====================================================================
>>>
>>>_______________________________________________
>>>Mip6 mailing list
>>>[e-mail]
>>>https://www1.ietf.org/mailman/listinfo/mip6
>>>
>>>
>>>
>>>      
>>>
>>-- 
>>------------------------------------------------------
>>Rafael Marin Lopez
>>Faculty of Computer Science-University of Murcia
>>30071 Murcia - Spain
>>Telf: [phone]    e-mail: [e-mail]
>>------------------------------------------------------
>>
>>
>>    
>>
>
>
>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.
>
>====================================================================
>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 send an e_mail to
>[e-mail]. Thank you
>====================================================================
>
>_______________________________________________
>Mip6 mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/mip6
>
>
>  
>


-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: [phone]    e-mail: [e-mail]
------------------------------------------------------


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