Subject: [Mip6] RE: review of draft-ietf-mip6-bootstrapping-split-00.txt

From: Gerardo Giaretta <[email-masked]>
Date: Wed, 21 Sep 2005 19:09:09 +0200

Hi Jari,

thank you very much for the review. Comments below..

> Hi,
> 
> I finally found time to read this document. Overall, its
> in very good shape, and I like the approach which
> provides a number of separate tools that together
> provide everything that you need for bootstrapping.
>

Good!
 
> Some comments below, however:
> 
> Technical:
> 
> >      5.3.2. Home Address auto-configuration by the Mobile Node 
> 
> This section probably needs some additional work. I'm not
> entirely happy with the approach, particularly the part where
> home addresses are authorized. I'm not sure I have a better
> suggestion, however.
> 

The mechanism described in this section tries to use the same approach
used in IPv6 stateless auto configuration in case the MN wants to auto
configure its HoA. This is the reason why we defined a new attribute,
MIP6_HOME_PREFIX, and we did not reuse the IP6_INTERNAL_ADDRESS
attribute. MIP6_HOME_PREFIX attribute is a kind of Prefix Option for the
home link. 

> One potential issue (and this is also an issue in [6]) is
> that the identity given in EAP-based authentication
> is not necessarily something that you can tie a long-term
> home address identity to. For instance, the identity
> could be a pseudonym (e.g. EAP-SIM), or a privacy NAI (e.g.
> RFC2486bis). 

I see the issue. I guess the same issue applies to VPN that makes use of
IKEv2-EAP. How is it handled in that case? Since the AAA server knows
the long-term identity of the MN, maybe the AAA server may have an
active role to create the matching between the identity and the HoA.

> Another issue is that it would seem to be
> useful that where CGA-based addresses are used that the
> home agent would actually check the ownership.
> 

I think what we should investigate better is how CGAs can be used with
MIPv6. And this is a problem that is different and seems orthogonal to
bootstrapping. The HA may check the ownership when receiving a BU (if
the MN includes a CGA option in the BU), while having this check
performed during IKEv2 exchange seems to me more problematic.

The usage of a CGA as HA may be useful to avoid some attacks in the home
link or having a more secure way to perform the returning home
procedure. However, I'm not sure if this is a problem related to
bootstrapping. If the check is done when receiving a BU, I think it is
orthogonal to bootstrapping. I don't see any reason (e.g. possible
attacks) why the check should be done during IKEv2 exchange, but maybe
I'm missing something.

> >         Additionally, it could be useful to provide an 
> ability for the 
> > Mobile
> >         Node to discover a Home Agent placed in a 
> particular location 
> > (e.g.
> >         on the visited link). In order to achieve this, the Mobile 
> > Node must
> >         be able to construct a DNS request such that the DNS server 
> > will be
> >         able to reply with a Home Agent from the requested 
> location. 
> > This can
> >         be accomplished by using a specific  naming 
> convention for the 
> > FQDNs
> >         of the Home Agents.
> 
> Possible, but the description is mostly handwaving and would probably
> benefit from a more generic solution in any case. Suggest
> removing this.
> 

I'm fine if we remove it. Vijay, any comment on that?

> >         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.
> 
> I haven't read [12] yet. I'm just wondering whether this communication
> is the same or very different from what a VPN gateway with IKEv2-EAP
> support needs. If its the same, you might note that here. (There's no
> spec for that either, but people still seem to be able to do that --
> with some interoperability issues though.)
> 

[12] is a bit obsolete and needs an update now that we have a solution
for bootstrapping. 

In my view, this communication should be very similar to what a VPN
gateway needs. However we need to investigate deeper on this. I started
to work with Hannes and Julien on this topic (see
draft-tschofenig-mip6-aaa-ha-diameter-00).

> >         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.
> 
> Hmm. An address authorization issue appears to come to the picture
> even in the home agent based solution. We don't want a mobile node
> M1 to take over the DNS name of mobile node M2. That's why the
> home agent, or someone, needs to authorize the use of a particular
> fqdn. This is later correctly noted, but not here.
> 

So, if I understand correctly, your point is that, even if the HA
performs the DNS update, it needs to get in touch with the AAA server
(or equivalent) to check if the MN is authorized to use that particular
FQDN. If so, I think it makes sense and I'll provide some text to
address it. 

> And then in Section 9.5:
> 
> >         Regardless of whether the AAA server or Home Agent 
> performs DNS
> >         update, the authorization of the Mobile Node to 
> update a FQDN 
> > MUST be
> >         checked prior to the performance of the update. It is an
> >         implementation issue as to how authorization is determined.
> 
> I'm not sure its just an implementation issue. If its the 
> home agent that
> performs such an update, then its likely that some AAA attributes
> are needed to support that (authorized-fqdn, 
> feel-free-to-trust-the-mobile-node-
> on-its-any-request attributes, for instance). Similarly, if its the
> AAA server that performs the update, then the fqdn needs to be
> carried in the protocol.
> 

Yes. These attributes are needed in the AAA-HA communication and should
be listed as goals for AAA-HA interface. 
In this draft we did not address AAA backend issues. Do you think that
text should be improved somehow? A reference to an update of [12] may be
useful, as we have done in section 6, paragraph 5.

> Editorial:
> 
> >         Node. The solution defined in this document solves the 
> > bootstrapping 
> 
> Typo.
> 
> >         there is not a Binding Cache entry, it sends a Neighbor 
> > Soliciation 
> 
> Typo.
> 
> >         network deployment model [4], even if it might not 
> be optimized . 
> 
> Extra space.
>

Thanks. I'll fix for next version.

--Gerardo
 
> --Jari

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: Jari Arkko <[email-masked]>
Date: Wed, 21 Sep 2005 20:18:47 +0300

>active role to create the matching between the identity and the HoA.
Well, there may be AAA ways of communicating this to
the home agent/vpn gateway, such as the use of the
Chargeable-User-Identity attribute, or some IP address
attributes. Some work would be need to study whether
those are sufficient or if something else is needed, and
in case all this would have to be documented somewhere
so that implementors would know what to do.

>I think what we should investigate better is how CGAs can be used with
Yes.

>performed during IKEv2 exchange seems to me more problematic.
I agree.

>attacks) why the check should be done during IKEv2 exchange, but maybe
You may be right.

>draft-tschofenig-mip6-aaa-ha-diameter-00).
Ok. The IPsec WG also had an unpublished draft long time ago
on the gateway - radius interface. Ideally, someone should
bother to actually publish that document and bring to an RFC..
and hopefully it would be a single document for both RADIUS
and Diameter, not sure if it should also combine VPN and Mobile IP...

>FQDN. If so, I think it makes sense and I'll provide some text to
Yes. The check may be an implementation issue, but before you
do the check, you need protocols to transport enough information
around so that you'll actually be able to make the check.

>useful, as we have done in section 6, paragraph 5.
It might be prudent to at least point out the requirement
to transport this particular piece of information, and perhaps
even stating that at the time of writing this no such attribute
has been defined for commonly used aaa protocols.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 21 Sep 2005 12:53:14 -0700

jak>> Remember that, if the MN uses a certificate rather than EAP for the 
IKE auth, the HA needs to check the FQDN in the certificate.

        jak

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Sep 2005 22:54:44 +0300

James Kempf wrote:

> Remember that, if the MN uses a certificate rather than EAP for the 

Yes.

--Jari