Subject: RE: [Mip6] Bootstrapping DT solution draft

From: Gerardo Giaretta <[email-masked]>
Date: Tue, 05 Jul 2005 18:58:40 +0200

Hi Mayumi,

thanks for your reply. Please see below.

>  >>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.
>  >>
>  >
>  >
>  > Could you please describe a scenario where the domain name 
> provider is
>  > different 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?
> 

This is a scenario that we have not considered during the DT work. If I
understand correctly, this would mean to introduce a new entity, a sort
of "naming service provider". Putting aside whether it is a good idea or
not, I think naming issues are out of scope of MIP6 bootstrapping. 

>  >>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?
>  >
>  >
>  > I think that, if there is a trust relationship between MSP and DNS
>  > provider (whatever it can be), the solution described in 
> the draft may
>  > also be applied in this scenario (it needs a AAA 
> communication between
>  > MSP and the domain name provider to authorize the usage of 
> a particular
>  > name and to update the DNS entry). But, let's discuss 
> about the scenario
>  > first.
> 
>   I agree that this solution can be applied.
>   The main point which I would like to ask is whether it is necessary
>   to describe DNS update in the body of the draft, not whether we can
>   apply this solution even if the trust relationship isn't 
> established.
> 

James have just deeply answered this issue.

>   IMHO, if we assume a simple scenario, we should not
>   assume any trust relationship between MSP and other provider.
> 

MSA and MSP MUST have a trust relationship in order to exchange
authentication and authorization data in a secure way.

Regards,
--Gerardo

> 
> Best Regards,
> --Mayumi
> 
>  > Regards,
>  > --Gerardo
>  >
>  >
>  >>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-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
>  >>[email-masked]. Thank you
>  
> >>====================================================================
>  >>
>  >>_______________________________________________
>  >>Mip6 mailing list
>  >>[email-masked]
>  >>https://www1.ietf.org/mailman/listinfo/mip6
>  >>
>  >
>  >
> 
> 
> 
> 

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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 21 Jul 2005 15:13:38 +0200

---

From: Gerardo Giaretta <[email-masked]>
Date: Thu, 21 Jul 2005 15:28:55 +0200

Hi Christian,

thanks for your comments. Please see inline.. 

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

Actually the AAA backend is out of the scope of the DT. There is a WG
item (draft-ietf-mip6-aaa-ha-goals) that described the goals for the AAA
backend interface. A new version of this document will be released based
on draft-ietf-mip6-bootstrap-split-00 and based on the solution for
integrated scenario we are working on. Then I guess that definition of
the AAA protocol should be done by AAA and RADEXT working groups. 

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

We use the same attribute for HoA assignment by the HA (i.e.
INTERNAL_IP6_ADDRESS attribute).
We use a different attribute for HoA auto-configuration (i.e.
MIP6_HOME_PREFIX): this is because the MN needs to be provided by a
network prefix and its length. This is not the purpose of
INTERNAL_IP6_ADDRESS that provides an IPv6 address to the peer.

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

In split scenario network access authentication and authentication for
mobility service are performed indipendently. That is ASA and MSA are
different entities. The DT is currently working on an integrated
solution for the scenario you mention.

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

We believe this is not an issue, even if there has been discussion in
the DT about that. 

The HA address can be recovered by other means anyway. If you are
referring to possible DoS attacks, I think that not revealing the HA
address during the HA Address discovery is not a viable solution. IKEv2
has mechanisms built in to discourage DoS. Moreover, the Home Agents,
like any other server in the network, should be protected against DoS
attacks, e.g. by overprovision.

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

I think both are possible. Do you think we need more text about this in
the draft?

--Gerardo

> Allright then.
> 
> - Christian
> 
> --
> Christian Vogt, Institute of Telematics, University of Karlsruhe
> www.tm.uka.de/~chvogt/pubkey/
> 
> 
> 
> Gerardo Giaretta wrote:
> > Dear WG,
> >
ing-split-
> > scenario (i.e. mobility service and basic network access 
> are authorized
> > by the same entity).
> >

---

From: Gerardo Giaretta <[email-masked]>
Date: Wed, 27 Jul 2005 11:55:16 +0200

Hi Rafa, 

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

MSA gives the authorization based on the user profile. This is the role
of the MSA. The AAA-MSP acts as a AAA proxy and, as for network access,
it can have an active role in this process. However, usually this is
based on roaming agreements between the providers.

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

We may add some text in the draft to clarify the role of the AAA-MSP.
But I would keep the distinction between MSA and MSP with the MSA that
authorized MIPv6 service based on the user profile. 

~snip~

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

MSA MUST explicitly do the authorization. MSP MAY be involved depending
on the scenario and the roaming agreements between the operators. Do you
agree on that?

> So I understand from this that MSP's AAA server is only doing routing.
> 

In my view usually it performs only AAA routing since based on roaming
agreements the authorization is implicit.

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

It depends on the FQDN used by the MN. If the FQDN belongs to the MSA<
the MSA MUST do that since the MSP AAA server may not share a SA with
the DNS server of the MSA.

Regards,
--Gerardo

> >  
> >
> >>>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: +34968367645 e-mail: [email-masked]
> >>------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>Gerardo Giaretta wrote:
> >>
> >>    
> >>
> >>>Dear WG,
> >>>
> >>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap
> >>>      
> >>>
> >>ping-split-
> >>    
> >>
> >>>00.txt.
> >>>
> >>>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]
> >>------------------------------------------------------
> >>
> >>
> >>    
> >>
> >
> >
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: +34968367645    e-mail: [email-masked]
> ------------------------------------------------------
> 
>