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

From: "James Kempf" <[email-masked]>
Date: Fri, 22 Oct 2004 17:00:59 -0700

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.

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.

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.

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.

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?

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.

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.

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

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.

            jak

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

---

From: Francis Dupont <[email-masked]>
Date: Sat, 23 Oct 2004 14:47:59 +0200

In your previous mail you wrote:

=> IMHO there cannot be "the" solution, but only some solutions which
can be used in particular contexts...
(note that I support the draft as a candidate too)

=> as it is the most advanced proposal IMHO it should be push.

=> I've lost most of my latin by "e.g." explicitely introduce an example.

   SAs with the home agent.

=> I disagree about the HoA address but you are 100% right about the HA
address.

=> 802.16 itself (i.e., the IEEE document without an extra letter or digit)
uses an authentication scheme derived from DOCSIS very different from EAP.

Thanks

[email-masked]

PS: it should be fine to collect implementation reports too (note this
remark should apply to all WG (relative) documents, including RFC 3775
and 3776).

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Oct 2004 08:32:22 -0700

Francis,

> => I disagree about the HoA address but you are 100% right about the HA

Sections 6.5 and 6.6 in RFC 3775 describe Home Agent address discovery,
based on the home subnet prefix (that's what I meant by requiring
topological information). So the base spec has a procedure, whether or not
the described procedure is deployable is of course another question.

> uses an authentication scheme derived from DOCSIS very different from EAP.

Section 6.3.2.3.9 (phew!) of the latest draft of 802.16e, the mobility
extension, specifies EAP for key managment. I'm not sure what 802.16d, the
updated air interface specification, specifies in this space, as I've yet to
crack its 900 pages.

            jak