Subject: Re: [MOBILE-IP] Personal I-Ds to WG work documents

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Apr 2000 09:13:50 -0700

>
> That's not *exactly* the way I recollect the discussion.  On the AAA Keys
> both Raj and I agreed that it should be a working group item but we were
> near the end of the second session and there was no time for any discussion.
> So, we'd like to hear from the working group on making this an item.

Well, I don't know exactly what I was on yesterday, but this document already
IS a WG document. I think that what we talked about was moving it to last
call. Sorry for the confusion. However, having said that, I just received some
comments that I wish to address before doing the last call.

I do remember this discussion since I had mentioned that interoperability had
already been done.

>
> On the first two, we'd like to hear from the working group.
>
> Personally I'd like to see the first two as working group items.  Since NAI
> is an RFC, and since we've already taken MIER, having a generalized NAI
> seems clearly within the scope.  I'm a little bit concerned about a growth
> of documents from the working group.  Is it worthwhile thinking about how to
> combine this with something else?  I guess I have the same comment on
> generalized keys.  Thoughts?

Well, I'm not sure what our options are here. We could:
1. Move them ahead separately (my preference) - They aren't the same thing
2. Combine them (and worry about authorship, since they aren't the same
co-authors) 3. Add them to yet another third document (and here the authorship
problems gets worse)

I don't necessarily agree with your argument of the number of documents. Take
a look at PPPEXT and IPSec WG, we aren't even close! Combining lots of
documents into one has the following disadvantages: 1. Longer through RFC
editor (rule: lowest byte count comes first) 2. Longer IESG review (longer
documents do take longer to review, and if they address many problems, that
makes it harder to review)

Take your pick. In either case, the AAA Keys cannot advance without the
Generalized Key draft (whether it is in that document, or combined in another
document).

PatC
>
> Phil
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, April 13, 2000 5:24 PM
> To: [email-masked]
> Subject: [MOBILE-IP] Personal I-Ds to WG work documents
>
>
> All,
>
> At the Adelaide IETF, the WG agreed to move the following documents to WG
> work
> documents:
>         - Generalized NAI I-D (draft-mkhalil-mobileip-gnaie-00.txt)
>         - Generalized Keys I-D (draft-perkins-mobileip-gen-key-01.txt)
>         - AAA Registration Keys I-D (draft-calhoun-mobileip-aaa-key-00.txt)
>
> In fact, the last one already has had implementations, and interoperability
> at
> the last Connectathon. Therefore, unless there are objections, I would like
> to
> see it go through last call.
>
> PatC

---

From: Roberts Phil-QA3445 <[email-masked]>
Date: Fri, 14 Apr 2000 09:36:01 -0500

Phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 13, 2000 5:24 PM
To: [email-masked]
Subject: [MOBILE-IP] Personal I-Ds to WG work documents

All,

PatC

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Apr 2000 09:36:56 -0700

I have just read the above document, and I have a couple of comments:

Section 3.3:

This section discusses the changes to the router advertisement. Specifically,
there is the introduction of the 'I' bit, and support for a GFA address in the
advert. I find support for advertising the localFA and the GFA to be
cumbersome. Is there any way why we cannot create a new router adv extension
to support the GFA? It would seem cleaner, and more compatible with existing
implementations.

Section 3.4.1:

I find that there are too many combinations supported, even one for an error
case. I agree that a GFA should be allowed to be assigned dynamically, but I
don't like the part where if the MN doesn't know what GFA was assigned, it can
pick one that was previously used. If no GFA was advertised, perhaps the new
advert GFA extension could specify that the local domain is able to assign
one, by setting a bit, for example. In either case, I don't like the Mobile
Node having to assume a GFA address.

Section 3.5:

Discussed elsewhere in this document, it is stated that the GFA is the box
that communicates with the AAA infrastructure. Therefore, it is reasonable to
assume that the keys generated would be shared between the Mobile Node and the
GFA (actually, this is also mentioned in the draft).

In this particular section, when the Mobile Node is issuing a regional
registration, it is supposed to add the MN-GFA auth extension. Is there a
particular reason why the MN-FA isn't used. I was under the impression that
the MN and the local FA didn't actually share a key, but it did with the GFA
instead. So I never see a case where the MN would use the MN-FA anyways.
Therefore, the MN-FA seems like a natural fit here.

Section 3.5.2.:

Perhaps this is reasonable, but the FA considerations restricts a Home Agent
from acting as a GFA. Perhaps this is OK, but it is a restriction, and not
obvious when reading the document.

Section 7:

Grammatical error: "If the Hierarchical Foreign Agent extension is appended to
the a registration request message, ..."

References:

[3] is in version 7
[4] is in version 9
[5] is now RFC 2794.

Appendix A:

I find that the following text has a little too much hand waving:
"
   We assume that security associations have been established among
   a GFA and all the foreign agents beneath it in the hierarchy.  As
   before, we assume that when a mobile node performs registration at
   its home network, registration keys are generated and distributed to
   the mobile node and to the GFA. The GFA may then in turn distribute
   the registration keys to the foreign agents beneath it in the
   hierarchy, using methods not specified in this document."

In the document, it is mentioned that the logical node that communicates with
the AAA infrastructure is the GFA. In introducing the RFA, how are the keys
propagated from the GFA to the RFA? This is needed in order to authenticate
the MN-FA auth ext,  and in my scenario, only the GFA has the keys. It would
be nice if the draft added some details on how the RFA could authenticate the
message without having to go up to the GFA.

That's all I have, for now.

PatC

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 14 Apr 2000 10:35:43 -0700

Hello Pat,

Thanks for your comments.  I first should mention two relevant
factors.

1) We will have a new draft before long.  During the recent IETF,
   after long discussions we three co-authors decided that it would
   be better (less ambiguous in certain cases) to have new message
   types instead of extensions as is the case currently.  We have
   gone back and forth on this issue, but in order to make use of
   regional registration the mobile node has to know anyway, so the
   backward compatibility issue is moot.  We originally wanted to
   have a regional registration look as much like a home registration
   as possible.  The packet layouts will still be almost identical,
   but the semantics will be able to be more clearly specified.

2) Gopal Dommety presented a draft idea for essentially a floating
   anchor approach in Adelaide.  We have always thought that this
   was a clear option that was to be supported in our draft, and
   in the new revision we will spell it out even more explicitly.
   It is pretty clear in the existing (and previous!) drafts that
   the mobile node is allowed to use the previous GFA.  We will make
   that very clear in the new draft.  As just consequence, however,
   I believe that there is no intellectual property that Cisco may
   claim on this idea.  I am not a lawyer, and I hope that I don't
   get hordes of lawyers breathing down my neck for making such
   statements.  But hey, I have to say what I think.

> to support the GFA? It would seem cleaner, and more compatible with existing

New extensions are indeed a "cleaner" approach, but they have to be
balanced against packet bloat.  It seems clear to me that we can do
with fewer bytes.  We should be sensitive to the needs of low-bandwidth
links since we are after all dealing with wireless networking.

> Node having to assume a GFA address.

But the mobile node has to be able to request the use of a previous GFA
whenever it can determine that doing so is a good thing.  Furthermore,
we would like our draft to be friendly to privately addressed FAs as
much as we can do so without becoming (normatively) dependent on whatever
eventual specification is written for such things.

> GFA (actually, this is also mentioned in the draft).

Yes.

> Therefore, the MN-FA seems like a natural fit here.

This could be done.  I don't claim otherwise.  However, since we do have
lots of MIERified extension subtypes, my feeling was that we could afford
to be extravagant and waste one because the mobile node would certainly
be able to tell the difference.  If the working group feels otherwise, I
will not make much protest.  I do like the idea of being as specific as
possible whenever there is no penalty for doing so.

> obvious when reading the document.

This is a restriction we would love to eliminate, but so far the good
idea has not floated into our general mental sphere of cognizance.
If you have a suggestion, please let us know.

> the a registration request message, ..."

Thanks for pointing these out.

> message without having to go up to the GFA.

But it's in the appendix.  We wanted to get the main body of the document
in good shape before tackling the harder issues collected into the appendix.
Furthermore, I think it is true that the way these issues would be resolved
will _depend_ on how the protocol in the main sections is finally decided.
Thus, we just collect together information in the appendix that we think
will eventually be useful.

Having said that, here is some pure speculation on my part, not informed
by the sanity of my co-authors.  I think that eventually we will have some
better ideas about how security associations are disseminated throughout
the multicast membership of a security domain.  This has something or
other to do with byzantine correctness, and is a goldmine for research
results.  Whatever the final answer is (or maybe there is already a final
answer), we should just use it.

Regards,
Charlie P.