|
List Info
Thread: multiple mobile-home authentication extensions in a single reg. request?
|
|
| multiple mobile-home authentication
extensions in a single reg. request? |
  United States |
2007-04-05 16:06:46 |
|
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: Howe ver, 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: plustwo mac.com">plustwo mac.com
|
| RE: multiple mobile-home authentication
extensions in a singlereg. request? |
  United States |
2007-04-11 12:17:54 |
|
|
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
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:
Ho wever, 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
AI M: plustwo mac.com">plustwo mac.com
|
[1-2]
|
|