Subject: RE: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt

From: Giaretta Gerardo <[email-masked]>
Date: Mon, 25 Oct 2004 18:31:51 +0200

Hi James,

thank you very much for reviewing the draft. See my comments below..

> This draft-giaretta proposes a solution for the dynamic bootstrapping
> problem that works for IASPs. It is not a solution for WISPs and other
> scenarios where the MSP is separate from the ASP.
> 
> I think this version of the draft is a considerable 
> improvement over the
> previous version. I believe it is a candidate for a WG draft for one
> solution (not *the* solution) to the dynamic bootstrapping 
> problem, that
> works for IASPs.
> 
> Working group chairs: can we have a concensus call in DC 
> after the draft is
> presented about whether the draft should be made a WG draft?
> 
> I have a few specific comments on the draft.
> 
> General editorial comment: In many cases, the authors have 
> parenthetical
> comments about possible protocols or mechanisms to achieve 
> some kind of
> result, for example, Section 3, Step 6:
> 
>    ...the MN gains network access and aquires a valid Care-of 
> Address within
> the visited subnet (e.g. via
>       stateless autoconfiguration).
> 
> In most cases, the mechanisms cited in the parenthetical 
> comments are not
> exhaustive, but only examplary. While reading the draft, I 
> was constantly
> noting other mechanisms that were missing and could be used. 
> I think it
> would be best to either drop these parenthetical comments or 
> include an
> exhaustive list. Otherwise, readers may think only the listed 
> mechanisms
> apply.
> 

In most cases our intention was to give only some possible examples to
accomplish a particular task (the configuration of the Care-of Address
in the case you mentioned). However, if you think it is better to have a
complete list, we could provide it in the next version, wherever it is
possible.

> Section 1, paragraph 1: This is a mischaracterization of the dynamic
> bootstrapping problem. The problem is not that there is no 
> way in RFC 3775
> to autoconfigure the HA addr and HoA addr. The problem is 
> that it is not
> possible to do that and, at the same time, dynamically 
> configure the IPsec
> SAs with the home agent. It is also not possible to configure 
> the HA addr
> and the HoA addr independently from statically configuring 
> some topology
> information on the MN.
> 

I see. We'll rephrase it in the next version. 

> Section 1, paragraph 4: The draft at this point lacks 
> sufficient clarity
> about how a roaming MN would be configured with a dynamically 
> assigned home
> agent in the foreign network. I believe that should be 
> mentioned, unless it
> is a goal of the authors to eventually encompass this 
> scenario in the draft.
> 

The allocation of the HA in the foreign network is an open issue in our
I-D. 
We tried to provide a solution in version 00. The basic idea was as
follows:
- in the EAP exchange the MN asks for a HA in the foreign domain
- AAAH gets in touch with AAAF via AAA protocol
- AAAF selects a Home Agent and communicates its address to AAAH
- AAAH forwards this information to the MN through EAP

We decided to remove this description because it is related to the
AAA-HA interface and does not affect the communication between MN and
AAA (that is the scope of this draft).

Do you think there are alternative solutions that affect the MN-AAA
interface and should therefore be described in the draft?

> Figure 2: Is the link between the MN and "AAA Client" 
> (presumably NAS or
> AAA-F) limited to 802.1x and PANA? I think not. Other Layer 
> 2.5 protocols
> might be used for other Layer 2, for example, 802.16 does not 
> use 802.1x for
> auth but does use EAP.
> 

I agree that figure 2 is misleading and too restrictive. Maybe "EAP
lower layer" in place of "802.1X or PANA" would sound better.

> Section 3, Step 4: The authors have a companion draft for deriving an
> application master key, wouldn't it be appropriate to cite 
> that draft at the
> end of this paragraph?
> 

Agreed

> Section 4: I think this section should be moved to an appendix. It is
> necessary and quite relevant, but not to the specification of 
> the protocol.
> 

Agreed.

> Section 5, paragraph 21: I'm not really sure the AAA server should be
> responsible for load balancing MNs among HAs. Some people in 
> IETF feel that
> even using EAP to distribute MIP bootstrapping information 
> isn't such a good
> idea. From the standpoint of the EAP protocol extensions 
> described in this
> document, it doesn't matter. I'd suggest dropping this from 
> the text, as it
> is rather something for the back end protocol between the HA and AAA-H
> server.
> 

Agreed that it is related to AAA-HA interface. I'll drop this in the
next version.

> Section 8.3: I would like a flag here indicating to the MN 
> that it should
> derive its HoA from IKEv2.
> 

This could be an interesting extension. 

BTW, do you think we need in the MN-AAA interface a mechanism to
negotiate the IKE version to be used between MN and HA?

> Section 8.8 and 8.9: Could these two options be combined? I 
> don't see any
> case where a message from the server would come with one and 
> not the other.
> 

If the negotiation fails, there will not be the
Authorization-Lifetime-AVP. 
So it may be better not to combine the two options. What do you think?

Regards,
--Gerardo

>             jak
> 
> 
> 
> _______________________________________________
> 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: "James Kempf" <[email-masked]>
Date: Mon, 25 Oct 2004 09:58:30 -0700

>interface and should therefore be described in the draft?

I think this should be dealt with in a separate draft, specifically targeted
at dynamic assignment of an HA in the foreign network. There is another
alternative, namely that AAAH tells MN to use DHCP to find the HA locally,
rather than finding it indirectly via AAA to AAAF. If there's a tight trust
relationship between the home and foreign service providers, this procedure
might be faster.

>lower layer" in place of "802.1X or PANA" would sound better.

Yes.

>negotiate the IKE version to be used between MN and HA?

Hmm, not sure. What does IKE itself provide? If there's adequate support in
IKE for version handling, then I think it isn't necessary. On the other
hand, the HA might support both and might want to control which one is used
by specific kinds of MNs.

BTW, I believe many IKEv1 implementations also provide address assignment,
though it is not part of the base specification. So just telling the MN to
use IKE address assignment probably isn't enough to determine whether IKEv1
or IKEv2 is used.

>So it may be better not to combine the two options. What do you think?

If the negotiation fails, then presumably there will be a Status option
indicating that, and the lifetime can be set to zero. Combining the two
avoids the overhead of an additional type and length.

            jak