Subject: [Mip4] multiple mobile-home authentication extensions in a single reg. request?

From: Paul C Lustgarten <[email-masked]>
Date: Thu, 5 Apr 2007 17:06:46 -0400

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: [email-masked]

-- 
Mip4 mailing list: [email-masked]
    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/

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Wed, 11 Apr 2007 10:17:54 -0700

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 [mailto:[email-masked]] 
Sent: Thursday, April 05, 2007 2:07 PM
To: [email-masked]
Subject: [Mip4] multiple mobile-home authentication extensions in a
singlereg. request?

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 ....

	    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.

[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: [email-masked]

---

From: Paul C Lustgarten <[email-masked]>
Date: Thu, 12 Apr 2007 14:24:55 -0400

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.

	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
>
> extension), only (and exactly) one instance of which was to appear  
> in each registration request:
>
> 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  
> 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.
>
> 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  
> So, what say you?  Is it every implementor for him/herself?   
> Declare a request with multiple instances of a given type of  
> 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: [email-masked]
>
>
>

______________
Paul C Lustgarten
+1 908 405 7919			Wireless Systems Research
AIM: [email-masked]		Bell Laboratories
[email-masked]			Alcatel-Lucent

---

From: Acee Lindem <[email-masked]>
Date: Fri, 13 Apr 2007 09:49:25 -0400

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

>> 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
>>
>> Subject: [Mip4] multiple mobile-home authentication extensions in  
>> a singlereg. request?
>>
>> 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  
>> 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.]
>>
>> 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.
>>
>> 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.
>>
>> 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: [email-masked]
>>
>>
>>
>
> ______________
> Paul C Lustgarten

---

From: "Chugtu Manish-a22653" <[email-masked]>
Date: Fri, 13 Apr 2007 22:25:56 +0800

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 [mailto:[email-masked]] 
Sent: Friday, April 13, 2007 7:19 PM
To: Paul C Lustgarten
Cc: Kent Leung ((kleung)); [email-masked]
Subject: Re: [Mip4] multiple mobile-home authentication extensions in a
singlereg. request?

Kent, Paul, 

	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

	

		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 [mailto:[email-masked]] 
		Sent: Thursday, April 05, 2007 2:07 PM
		To: [email-masked]
		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 ....

		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.

		[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: [email-masked]

	______________
	Paul C Lustgarten

	-- 
	Mip4 mailing list: [email-masked]
	    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/

---

From: Acee Lindem <[email-masked]>
Date: Fri, 13 Apr 2007 11:24:52 -0400

On Apr 13, 2007, at 10:25 AM, Chugtu Manish-a22653 wrote:

> 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.

The fact that this extension is non-skippable (36) implies that all  
parties involved must understand it.  Hence, in this case, multiple  
instances could be accepted. However, it doesn't appear that RFC 4721  
covers the case of sending multiple MN-AAA extensions (as identified  
by both the type and sub-type) or how one would associate one with  
the FA and the other with the HA (although I only gave it a quick  
read).  Also, I don't see why the MN-AAA extension couldn't apply to  
both the FA and the HA.

Thanks,
Acee

> Subject: Re: [Mip4] multiple mobile-home authentication extensions  
> in a singlereg. request?
>
> Kent, Paul,
>
>> 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.
>
> 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
>>
>>
>>> 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.
>>>
>>> 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?
>>>
>>> extension), only (and exactly) one instance of which was to  
>>> appear in each registration request:
>>>
>>> However, RFC 3344bis has revised and generalized this condition  
>>> to require *at least* one authorization-enabling extension:
>>>
>>> So, as best as I can recall from before "issue19" went to meet  
>>> its maker (or at least went undercover), the history of this  
>>> 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.
>>>
>>> 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: [email-masked]
>>>
>>>
>>>
>>
>> ______________
>> Paul C Lustgarten