Subject: Re: [mobile-ip] Re: mobile-ip] WG last call: draft-ietf-mobileip-gen-key-00.txt

From: Alpesh Patel <[email-masked]>
Date: Fri, 20 Jul 2001 15:35:03 -0700 (PDT)

Pat,

Please see my questions below:

> > We've just started following this draft and are trying to grasp its
> > intent.  We have a few questions/comments:
> > 
> > 1.  Since it is not specified, can the 'Reply' Key extensions be
> > appended to both RPYs and RRQs?
> 
> No. Request goes in Registration Request, while Reply goes in the Registration
> Reply.

Why this restriction? This essentially supports the request response or
uninitiated response model. We envison a situation where we would need 
a push model to configure the keys at an entity which has not yet taken
part in mobile ip signaling. We can potentially achieve the equivalent 
of 'push' model, but that would require two round trip worth of signaling
effort. 

> 
> > 
> > 2.  Section 7, 'FA-FA Key Reply Subtype Data' sounds like a
> > description for MN-HA Reply.
> 
> I think you mean FA-HA, and the text is incorrect.
> 
> > 
> > 3.  Are the 'Reply' Key extensions in Sections 6 and 7 sent
> > unsolicited by a mobility agent (MA)?  Actually, who is sending these
> > extensions and how do they even know to send these extension?  Also,
> > in what MIP messages are these being sent?  Please explain this a bit.
> 
> AS far as section 6, its use depends upon the context. As far as AAA
> is concerned, it isn't used because AAA transfers the keying information
> instead of within MIP. However, I presume that there are cases where
> the FA and/or HA wish to exchange keying information. We decided that it
> made sense to include this case, since it will most likely be needed 
> sometime in the future.
> 
> As far as section 7, it could be useful in hierarchical scenarios.
> 
> > 
> > 4.  Can the 'Reply' Key extensions in Sections 3 and 5 be sent
> > unsolicited to the MN...meaning, not in response to a 'Request' Key
> > extension.
> 
> if it is requested, then it is returned. However, it *could* be unsolicited.

Can you add a note in the draft/rfc that reply messages could be sent 
unsolicited? This will probably avert confusion - either way. We need
the scenario where keys can be pushed without solicitation.

> 
> > 5.  Curious...why separate Types for each message?  Why not
> > Type = Key Distribution message,
> > Subtype = MN-HA, MN-FA, FA-HA, etc
> > First byte of Subtype = serve purpose of current Subtype?
> 
> We thought that a separate type for each peer set made sense. We don't
> use that many, and even if a subtype wasn't recognized, you'd still have
> an idea whether you need the key or not (and return the appropriate error).
> 
> Example. Let's assume an FA receives a packet with one of these mumbo
> extensions you mention above. If the subtype isn't recognized, it doesn't
> know whether the key is destined for it or not. Perhaps the key is really 
> for the mobile node instead.
> 
> Make sense?

Hmm, but wouldn't the location of this extension in the registration 
request/reply take care of this? If the extension if located before
MHAE then it is for MN and after MHAE and optionally before FHAE, the
FA is supposed to interpret it. I am just trying to conserve the 
numbering space here - no intention to be picky. 

> 
> > 6. When MN sends 'MN-HA Key Request' extension in RRQ, does it append
> > MN-AAA AE since no MHAE?  So, AAA is doing proxy authentication of MN
> > for the HA?  Then, HA sends RPY with 'MN-HA Key Reply'
> > extension...what AE is used to secure the RPY?
> 
> They are independent. If the MN includes the MN-HA Key Request with the
> AAA subtype (see AAA keys draft), then it really should include the
> MN-AAA extension. However, these are separate drafts, and it makes sense
> to leave it that way.

I think I am not clear - if the MN is requesting the key, then it essentially
does not have the key to HA. Thus, it cannot use MHAE to authenticate the
message. The original question was what AE is used to authenticate the
message. We know MN-AAA extension is a separate extension and are speculating
if that extension is used to authenticate the MN?

> 
> You are correct, though, that the HA would include the MN-HA Key Reply
> extenion in the reply message, with the MN-HA auth ext generated using the
> newly distributed key.

A note in this regard would help clarify processing at the receiving 
entity - that the just generated key should be used to authenticate the
received message.

> 
> > 
> > 7. We would like a mobility agent, say MA-1, to pass key to MA-2 for
> > MA-2 to use with MN.  If MAs are FAs, then probably the FA-FA Key
> > Reply Extension would be used...appended to what MIP message?  What if
> > the MAs are HAs?
> 
> Since this behavior hasn't been defined, I cannot claim to know. This
> draft only defines the generalized extensions, but separate extension
> documents would describe how they are used. aaa keys is one such example.

Can you add a section to distribute the keys between two HA's in an
administrative domain? - something like HA-HA key distribution extension?

Thanks
Alpesh

> 
> > 8. Section on user scenarios would be helpful...mention that the AAA
> > Registration Keys draft is an instantiation of this draft. A simple
> > user scenario would illustrate the intent of the draft.
> 
> We had decided NOT to create a double link list. The AAA keys draft already
> points to this draft, and the other way around doesn't make a whole lot
> of sense.
> 
> The AAA draft, which describes subtypes, provides the needed illustration.
> I would hate to have to copy that text into this simple draft, because it is
> so AAA specific.
> 
> Thanks,
> 
> PatC
> > 
> > Thanks,
> > Madhavi
> > 
> > On Fri, Jul 06, 2001 at 01:55:02PM -0400, Phil Roberts wrote:
> > > 
> > > This is a Mobile IP WG last call for the I-D
> > > draft-ietf-mobileip-gen-key-00.txt
> > > Generalized Key Extensions for Mobile IP. This draft will be sent to the
> > > IESG
> > > requesting a proposed standard status to be associated with it at the end 
of
> > > the last call period. Please send your comments to the WG discussion list.
> > > 
> > > WG Last call issued on : Jul 5, 2001
> > > Expires on : Jun 20, 2001
> > > 
> > > Basavaraj Patil
> > > Phil Roberts

-a