RE: multiple mobile-home authentication extensions in a singlereg. request?

Hi All,

 

A bit late on this thread. Looking from what we are talking about - well simply put - we shouldn't be allowing multiple extensions of the same type in the request. But if I understand correctly, wonder how would this work for MN-AAA Auth extension. MN can normally send this for both FA as well as HA (if we need MN-AAA authentication with both of them i.e.: AAA generating keys for both MN-FA and MN-HA), hence having both of them with the same type ( The reason being we don't have MN-AAA-FA and MN-AAA-HA, we only have MN-AAA).

 

This is one case I could think of where multiple extensions having the same type, would be a part of the request ( at least till FA, before it strips its part and sends it to HA). Wonder if this isn't how it was intended to be used, as FRS is not clear about that.

 

Thanks and Best Regards

Manish Chugtu

---

From: Acee Lindem [ aceelindem.com">mailto:aceelindem.com]
Sent: Friday, April 13, 2007 7:19 PM
To: Paul C Lustgarten
Cc: Kent Leung ((kleung)); mip4ietf.org">mip4ietf.org
Subject: Re: [Mip4] multiple mobile-home authentication extensions in a singlereg. request?

Kent, Paul,

On Apr 12, 2007, at 2:24 PM, Paul C Lustgarten wrote:

Kent,

Thanks for your reply.   And good, it sounds like I was on the right track, then.  So I would hope/propose that, when this part of RFC 3344bis gets revised, it would also specify that a home agent that receives a registration request with more than one instance of a given type of authorization-enabling extension SHOULD reply with an error code of 131.

Why wouldn't this fall into the category of a poorly formed request or reply (error codes 70/71 for FA and 134 for HA)?  Does this imply that MIP4 packets with duplicate non-skippable extensions should be accepted?  I know of at least one implementation that catches these today ;^)

Thanks,

Acee 

Paul

On Apr 11, 2007, at 1:17 PM, Kent Leung ((kleung)) wrote:

Hi Paul.

 

It doesn't seem to make sense to have multiple authorization-enabling extensions of the same type in the registration message.  I don't remember the history of this topic and agree with what you had recalled about the intention of supporting MN-HA Auth Ext, MN-AAA Auth Ext, and any future Auth Ext.  I agree that it would be good to specify that there must not be more than one of the _same type_ in the message.

 

It would be useful to be able to dig up the issue19 archive to make sure that we're not overlooking anything that had been discussed.

 

Kent

---

From: Paul C Lustgarten [ plusbell-labs.com">mailto:plusbell-labs.com]
Sent: Thursday, April 05, 2007 2:07 PM
To: mip4ietf.org">mip4ietf.org
Subject: [Mip4] multiple mobile-home authentication extensions in a singlereg. request?

Hi.  I have a question about MIPv4 that seems to have become an unspecified detail as of RFC 3344bis. 

Specifically, is a registration request allowed to contain multiple instances of a *given* authorization-enabling extension?  In particular, is it permissible for a request to contain multiple instances of the mobile-home authentication extension?

In RFCs 2002, 3220, and 3344, such a multiplicity was cleared prohibited, because there was only one *type* of authorization-enabling extension recognized (the mobile-home authentication extension), only (and exactly) one instance of which was to appear in each registration request:

   Exactly one Mobile-Home Authentication Extension MUST be present in 

   all Registration Requests and Registration Replies, and ....

-- section 3.5.2 (same text in all 3 RFCs)

However, RFC 3344bis has revised and generalized this condition to require *at least* one authorization-enabling extension:

    At least one authorization-enabling extension MUST be present in 

   all Registration Requests, and also in all Registration Replies 

   generated by the Home Agent.  The Mobile-Home Authentication 

   Extension is always an authorization-enabling for registration 

   messages specified in this document.

-- section 3.5.2, RFC 3344bis

[I believe this actually *means* to say "in EACH Registration Request", and not as it literally reads, that the same extension(s) (whichever one or more those are) must appear "in ALL Registration Requests".  Ah, the precise use of quantifiers is such fun.]

What this leaves unspecified is whether multiple instances of a single type of authorization-enabling extension are allowed.

Some months ago, I read up on the history of this issue, which previously appeared as "Issue 19" at this URL:

http://www.mip4.org/issues/tracker/mip4/issue19

However, the web site at that URL seems to have succumbed to Alzheimer's--for some weeks now, every time I access it, I get only a page full of error messages, headlined by one about it having "no attribute '_load_phython'". Dropping back a step, and going in the (virtual) "front door" of http://mip4.org , and clicking on the conveniently-placed "Issues" link near the top of that page, takes me now to some page for "Mip4 Status Pages" and "Active Tickets", with nary a sign of any "issues" nor anything numbered "19".  Oh, and this page, too, conveniently has an "Issues" entry in the navigation bar near the top of the page ... but, alas, it leads only back to this same page.

So, as best as I can recall from before "issue19" went to meet its maker (or at least went undercover), the history of this change in section 3.5.2 seems to have been driven by the need to accommodate the existence of multiple types of authorization-enabling extensions.  That makes sense.  But I also saw nothing to suggest that there was any desire or attempt to allow multiple instances of the same type of authorization-enabling extension in a single registration request.  Maybe that concept would make sense for some other type of such extension, but I have yet to devise any reason it would be good to allow multiple instances of a mobile-home authentication extension in a registration request.

So, what say you?  Is it every implementor for him/herself?  Declare a request with multiple instances of a given type of authorization-enabling extension to be malformed & trigger an error reply with code 131 (MH failed authentication), as was stipulated for this case prior to 3344bis?  Process only the first of each type of authorization-enabling extension to appear in a given registration request?  Or only the last?  Or all of them?  And if all of them, is it sufficient for at least one to pass?  Or must all pass?  ?  ?  ?    (Inquiring minds are herewith stumped. :-(  )

Thanks,

Paul

______________

Paul C Lustgarten

+1 908 405 7919

AIM: plustwomac.com">plustwomac.com

______________

Paul C Lustgarten

+1 908 405 7919 Wireless Systems Research

AIM: plustwomac.com">plustwomac.com Bell Laboratories

plusbell-labs.com">plusbell-labs.com Alcatel-Lucent

-- 

Mip4 mailing list: Mip4ietf.org">Mip4ietf.org

    Web interface: https://www1.ietf.org/mailman/listinfo/mip4

     Charter page: http://www.ietf.org/html.charters/mip4-charter.html

Supplemental site: http://www.mip4.org/