Subject: Re: [Mip6] Bootstrapping DT solution draft

From: Mayumi Yanagiya <[email-masked]>
Date: Mon, 04 Jul 2005 17:58:02 +0900

Hi James,

 > What is the "domain provider"? A separate administrative entity from 
the MSP
 > or MSA?

  I think that MN can be assigned FQDN, which is used for IP 
reachability, from "domain provider" such as “Yahoo! Domain”.
Is my understanding correct?

 > If so, then what network entity will be updating the DNS server with 
the HoA
 > (which the MN will get from the MSP)?

  I don’t think that network entity can update DNS server with HoA when 
“domain provider” is separated from MSP or MSA. Only MN can update DNS 
server after binding update has been completed successfully.

--Mayumi

 >             jak
 >
 > ----- Original Message -----
 > From: "Mayumi Yanagiya" <[email-masked]>
 > To: "Gerardo Giaretta" <[email-masked]>
 > Cc: <[email-masked]>
 > Sent: Wednesday, June 29, 2005 8:36 PM
 > Subject: Re: [Mip6] Bootstrapping DT solution draft
 >
 >
 > Hi Gerardo and solution DT members,
 >
 > First, I'd like to express my appreciation for your work.
 >
 > I have a comment about dynamic DNS update in this draft.
 >
 > In section6, it is described that dynamic DNS update function is
 > important to keep IP reachability when MN is assigned HoA dynamically.
 > I agree this. But, is it essential function for MIPv6 bootstrapping?
 > I think we can use FQDN assigned by a domain name provider, which is
 > different from MSP/MSA, for IP reachability even if we get HoA from MSP.
 >
 > I understood that DT has selected the split scenario, which was simpler
 > scenario, in order to make the first solution generic. In the split
 > scenario, we don’t assume that there is relationship between MSP and
 > access service provider. Should we assume that there is relationship
 > between MSP and DNS provider?
 >
 > Best Regards,
 > --Mayumi
 >
 >
 >>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-bootstrapping-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
 >>[email-masked]. Thank you
 >>====================================================================
 >>
 >>_______________________________________________
 >>Mip6 mailing list
 >>[email-masked]
 >>https://www1.ietf.org/mailman/listinfo/mip6
 >>
 >
 >

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 05 Jul 2005 13:30:57 +0200

Hi Gerardo, DT members

Firstly, i would like to thank you about this so expected work.

Following, please see inline my comments...

<snip>

>
> 3. Split scenario
> In the problem statement draft [4] there is a clear assumption that 
> mobility service and network access service can be separate. This 
> assumption implies that mobility service and network access service 
> may be authorized by different entities. As an example, the service 
> model defined in [4] allows an enterprise network to deploy a Home 
> Agent and offer Mobile IPv6 service to a user, even if the user is 
> accessing the Internet independent of its enterprise account (e.g., by 
> using his personal WiFi hotspot account at a coffee shop).
> Therefore, in this document it is assumed that network access and 
> mobility service are authorized by different entities, which means 
> that authentication and authorization for mobility service and network 
> access will be considered separately. This scenario is called split 
> scenario.
>
>
> Moreover, the model defined in [4] separates the entity providing the 
> service from the entity that authenticates and authorizes the user. 
> This is similar to the roaming model for network access.
>
$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??

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.

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).

> 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.

>
> 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?

<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??

> 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.

>
>
> 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...??

> 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??

> 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??

> 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??

So far, these are my comments.

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645 e-mail: [email-masked]
------------------------------------------------------

Gerardo Giaretta wrote:

>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.
>

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Tue, 5 Jul 2005 09:11:36 -0700

Mayumi,

>server after binding update has been completed successfully.

We discussed this at some length in the DT and the concensus is that there
is no way to prevent redirection attacks if the MN does the update. There is
no provision for return routability in dynamic DNS, so a MN could update the
DNS with an address that it was not at, and thereby DoS a victim, just as
with MIPv6 return routability.

            jak

---

From: Li Qin <[email-masked]>
Date: Wed, 20 Jul 2005 16:11:53 +0800

I guess that multiple home agents related issues, such as dynamic home
agent assignment, have not been considered in this draft.

if so , can you tell us the reason?

---

From: "James Kempf" <[email-masked]>
Date: Wed, 20 Jul 2005 09:24:30 -0700

The home DNS server can contain multiple HA addresses in the SRV record.

        jak

----- Original Message -----
From: "Li Qin" <[email-masked]>
To: "Gerardo Giaretta" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 20, 2005 1:11 AM
Subject: Re: [Mip6] Bootstrapping DT solution draft

S.p.A.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 20 Jul 2005 11:00:21 -0700

once the mobile node knows the home prefix, it can still do
DHAAD if it wants to.

Vijay

---

From: Christian Vogt <[email-masked]>
Date: Wed, 20 Jul 2005 21:40:03 +0200

Hi Gerardo, hi DT members,

thanks for the bootstrapping I-D; you did a very good job!

Some comments (and questions) from my side:

(1)  The DT draft doesn't yet specify the backend AAA protocol, e.g., a
Diameter application.  Is this your next step?  (IMO, considering a
split scenario makes sense only when you specify the AAA protocol, too,
because that AAA protocol---neither the DNS lookup nor the MN-HA IKEv2
exchange---is affected by the split.)

(2)  Draft-ietf-mip6-ikev2-ipsec-01.txt already defines how to
dynamically assign a HoA during the IKEv2 handshake.  Why do you use
different Configuration Payloads?

(3) In order to contact DNS, the MN needs IP connectivity.  Is your
assumption that the visited network (ASP/ASA) authorizes the MN for IP
connectivity first, and the MN bootstraps Mobile IPv6 thereafter?  (This
would preclude an all-in-one solution like, e.g., the one described in
draft-le-aaa-diameter-mobileipv6-04.txt.)

(4) Are you assuming that the DNS server belongs to the MSA?  If not,
the MN probably won't have an SA with the DNS server, so DNS requests
are unauthenticated and DNS responses are not encrypted.  (Note that I
am NOT talking about DNS updates here.)  As a consequence, information
about the home topology is accessible to anybody.  Is this an issue?

(5)  The DNS server can store multiple HA addresses, so dynamic HA
assignment is possible in principle.  Do you assume that the DNS server
is in charge of load balancing or that it can assign a HA topologically
close to the MN?  (Fault tolerance could be handled by DHAAD.)

Allright then.

- Christian

--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

---

From: Li Qin <[email-masked]>
Date: Thu, 21 Jul 2005 23:33:47 +0800

In my opinion I think its more like a HA discovery than HA assignment.

If multiple HAs are deployed in home network, is it possible to assign a
HA according to the user's profile, or according to current load of the
HAs in this solution?

---

From: Li Qin <[email-masked]>
Date: Fri, 22 Jul 2005 00:50:11 +0800

There are many issues discussed in WG related to DHAAD. For example:
security issue and anycast address issue.

Also, I think we cannot actually _assign_ an HA using DHAAD, right?
In DHAAD, HA address is discoverd and selected by MN, not be assigned
by MSP.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 22 Jul 2005 07:51:54 -0700

The SRV record contains information that the operator can use to establish a
preference ordering on the servers for clients. That said, I don't believe
it is intended to provide fast, real time information about preferences, say
on the order of seconds., but more over longer periods, since dynamic DNS
updates require some time to propagate, and it would also not be such a good
idea to burden the DNS server with having to handle such frequent updates.

Its also possible for the HAs themselves to refuse new IKEv2 connections if
they are loaded. Since the MN will have a list of HAs, it will just roll
over to trying the next one.  The HAs could co-operate somehow (maybe using
a protocol like HAHA?) to establish which HA should be taking new
connections. This could be used to perform finer grained load balancing.

Make sense?

            jak

----- Original Message -----
From: "Li Qin" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Li Qin" <[email-masked]>; "Gerardo Giaretta"
<[email-masked]>; <[email-masked]>
Sent: Thursday, July 21, 2005 8:33 AM
Subject: Re: [Mip6] Bootstrapping DT solution draft

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Jul 2005 11:49:11 -0700

> In DHAAD, HA address is discoverd and selected by MN, not be assigned

actually you can, by adjusting the HA preference value. the
list of HAs in a DHAAD reply is ordered based on the HA's
preference value.

but I understand what you are getting at.

one option is to use
http://www.ietf.org/internet-drafts/draft-haley-mip6-ha-switch-00.txt
to switch the mobile node to another HA.

we dont have any other solution currently.

the current bootstrap solution is for the split scenario. the
bootstrap design team just started working on the integrated
scenario. in the integrated scenario the HA can be assigned
by the AAAH during network access authentication.

Vijay