Subject: [Dime] Relationship between draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and draft-sarikaya-dime-prefix-delegation-ps-01.txt

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Jul 2008 15:41:16 +0300

I have sent my rechartering questions around regarding these two 
documents. I took a brief look at them and I wonder what the 
relationship between the two documents is. Why are there 2 documents on 
almost the same subject?

When I browse through 
http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt 
then I sometimes get the impression that you would like to later 
standardize a Diameter application. I wasn't sure why additional AVPs 
aren't sufficient, in case existing AVPs cannot be re-used?

Let me also comment on a few selected items:

AAA-based prefix authorization (PA) application MUST run between a NAS, 
located on AR, LMA, MR, etc. and an AAA server.

[hannes] This requirement does not say a lot. The AAA protocol is always 
run between a client and a server.

AAA-based PA application MUST support the AAA client to request prefixes 
from an AAA server. AAA-based PA application MUST support the client to 
give back the prefixes to the AAA server.

[hannes] With the last sentence you mean that you need to have a way to 
indicate that the AAA session is terminated?

If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices on 
the network, the certificate or the information needed to obtain a 
certificate SHOULD also be sent by the AAA server to NAS.

[hannes] What information do you exactly want to carry towards the AAA 
client?

In point-to-point link operation, the NAS MUST identify the interface of 
MN in its request. The NAS MAY provide a prefix hint, e.g. of length /48 
to which the AAA server MUST reply with one or more prefixes, e.g. of 
length /64.

[hannes] how would such an interface identifier look like?

In point-to-point operation, the AAA server MAY assign the prefix(es) 
and related parameters such as the lifetime and the certificates to MN 
from MN's profile.

[hannes] I am not sure what this means. You mean that the AAA server 
should keep state to make sure that it does not forget what it has 
provided to the MN?
For some reason the problem is not well described. In Section 3 of 
draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC 4818 
but I do not quite understand what you would like to see happening instead.

AAA-based prefix authorization application SHOULD support prefix release 
procedures.

[hannes] isn't this the same as mentioned in the previous requirement 
"AAA-based PA application MUST support the client to give back the 
prefixes to the AAA server. "

The NAS is responsible for renewing the prefixes when the lifetime 
expires. The NAS SHOULD be able to extend the lifetime of the prefixes 
using messages designed for this purpose.

[hannes] Why wouldn't we tie the lifetime of the prefix to the lifetime 
of the AAA session itself? Makes things much easier. The same applies a 
bit to this requirement: "It SHOULD be possible to renumber the prefixes 
authorized by AAA server. The AAA server SHOULD initiate prefix 
renumbering process. "

RFC2119 seems to be a bit randomly used in the document.

Ciao
Hannes

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Frank Xia <[email-masked]>
Date: Wed, 23 Jul 2008 11:55:03 -0500

Hi Hannes

I try to jump ahead of Behcet to  answer
some of your questions :-)

Please check inline comments.

BR
Frank

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 23, 2008 7:41 AM
Subject: [Dime] Relationship between 
draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and 
draft-sarikaya-dime-prefix-delegation-ps-01.txt

>I have sent my rechartering questions around regarding these two documents. 
>I took a brief look at them and I wonder what the relationship between the 
>two documents is. Why are there 2 documents on almost the same subject?
>
Frank=>They have almost the same main idea.
You can only refer to the draft
http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt.

> aren't sufficient, in case existing AVPs cannot be re-used?
Frank=>Prefix delegation is an authorization which may be
decoupled from an authentication. RFC4005/4072 only deal
with coupled authentication& authorization scenario.

> indicate that the AAA session is terminated?
Frank=>In IPv6 renumbering scenario, it is necessary

> [hannes] What information do you exactly want to carry towards the AAA 
Frank=>IPv6 address prefix for NAS is authorized to route

> [hannes] how would such an interface identifier look like?
Frank=>Tentatively, it can be the interface identifier part of host's link 
local
address, NAI (RFC4282), or MAC address.

>
> In point-to-point operation, the AAA server MAY assign the prefix(es) and 
> related parameters such as the lifetime and the certificates to MN from 
> MN's profile.
>
Frank=>Probably, the AAA server for prefix delegation is different from
the AAA server for authentication.  So it is necessary to record the state.

> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC 4818 but 
> I do not quite understand what you would like to see happening instead.
>
Frank=>It is the same.

> [hannes] Why wouldn't we tie the lifetime of the prefix to the lifetime of 
> the AAA session itself? Makes things much easier. The same applies a bit 
> to this requirement: "It SHOULD be possible to renumber the prefixes 
Frank=>IPv6 renumbering is a feature of IPv6.
If we tie the lifetime of prefix to the lifetime of AAA session,
it is certain that we can't suport IPv6 renumbering.
Even though IPv6 renumbering probably happen probably
infrequently, it is better for us to have such a mechnism to support.

For IPv6 renumbering, here are some references
RFC 1916/2071/2072/2874/2894/4076/4192.

> RFC2119 seems to be a bit randomly used in the document.
Frank=>We will polish the draft,
and also welcome more poeple to join us.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Jul 2008 22:30:38 +0300

Hi Frank,

thanks for the quick feedback.

I have a few more comments inline

Frank Xia wrote:
> ----- Original Message ----- From: "Hannes Tschofenig" 
> <[email-masked]>
> To: <[email-masked]>
>> relationship between the two documents is. Why are there 2 documents 
>> on almost the same subject?
>>
Ok. We can essentially forget the other document. Right?

> with coupled authentication& authorization scenario.
It is true that the request for prefix authorization is not run 
independently from the message exchanges used for authentication.

>> AAA-based prefix authorization (PA) application MUST run between a 
>> NAS, located on AR, LMA, MR, etc. and an AAA server.
>>
>> [hannes] This requirement does not say a lot. The AAA protocol is 
>> always run between a client and a server.
>>
>>
>>
>> AAA-based PA application MUST support the AAA client to request 
>> prefixes from an AAA server. AAA-based PA application MUST support 
>> the client to give back the prefixes to the AAA server.
>>
>> [hannes] With the last sentence you mean that you need to have a way 
>> to indicate that the AAA session is terminated?
>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the devices 
>> on the network, the certificate or the information needed to obtain a 
>> [hannes] What information do you exactly want to carry towards the 
>> AAA client?
I mean, you want to provide
* prefix
* lifetime
* certificate
from the AAA server to the AAA client.
What else?

>>
>> In point-to-point link operation, the NAS MUST identify the interface 
>> of MN in its request. The NAS MAY provide a prefix hint, e.g. of 
>> length /48 to which the AAA server MUST reply with one or more 
>> prefixes, e.g. of length /64.
>>
> Frank=>Tentatively, it can be the interface identifier part of host's 
> link local
I would like to better understand what the AAA server should be doing 
based on this hint.
Is the "hint" used to identify the end user and it's host?

>> and related parameters such as the lifetime and the certificates to 
>> MN from MN's profile.
>>
OK.

I don't think that you need to say that since this is already done today.

>> AAA-based prefix authorization application SHOULD support prefix 
>> release procedures.
>>
>> expires. The NAS SHOULD be able to extend the lifetime of the 
>> prefixes using messages designed for this purpose.
>>
>> [hannes] Why wouldn't we tie the lifetime of the prefix to the 
>> lifetime of the AAA session itself? Makes things much easier. The 
>> same applies a bit to this requirement: "It SHOULD be possible to 
>> renumber the prefixes authorized by AAA server. The AAA server SHOULD 
>> initiate prefix renumbering process. "
I know IPv6 renumbering but I was wondering about the following issue.

IPv6 renumber should occur less frequently and hence the lifetime is 
rather long.
A AAA session typically isn't very long lived and it is possible to 
influence the lifetime with various parameters.

Now, isn't it possible to re-authenticate and re-authorize the end host 
in case of network renumbering. Given that you have to re-authenticate 
quite often for other reasons as well shouldn't cause big problems.

I am just trying to figure out how tough the requirements are.

Ciao
Hannes

---

From: Frank Xia <[email-masked]>
Date: Wed, 23 Jul 2008 15:01:04 -0500

Hi Hannes

Please check my reply..

BR
Frank
----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 23, 2008 2:30 PM
Subject: Re: [Dime] Relationship between 

> Ok. We can essentially forget the other document. Right?
Frank=>Yes.

> independently from the message exchanges used for authentication.
Frank=>A little bit confusing.   You meant "independently " or not?

> from the AAA server to the AAA client.
Frank=> I can only find these now.

> Is the "hint" used to identify the end user and it's host?
Frank=>The hint is only for expressing client's preference.  The
server may honor this or not based on it's own discretion.

> influence the lifetime with various parameters.
Frank=>IMHO, I don't agree with your assumption on AAA session lifetime.
In fact, many people including me are always online because many operators
don't charge based on time.  For example, $30 a month is for no limited 
access.

>
> Now, isn't it possible to re-authenticate and re-authorize the end host in 
> case of network renumbering. Given that you have to re-authenticate quite 
> often for other reasons as well shouldn't cause big problems.
Frank=>IMHO, it is not very graceful to kick off all the users
when renumbering.
> I am just trying to figure out how tough the requirements are.
Frank=>IMHO, it is very hard to figure out before widely IPv6 deployment.
However, it is probably too late after large scale deployment.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Jul 2008 23:13:21 +0300

Hi Frank,

Frank Xia wrote:
>>>> relationship between the two documents is. Why are there 2 
>>>> documents on almost the same subject?
>>>>
>>>> standardize a Diameter application. I wasn't sure why additional 
>>>> AVPs aren't sufficient, in case existing AVPs cannot be re-used?

I agree with you that RFC 4072 combines the prefix authorization 
protocol run with the EAP protocol run.

RFC 4005 is a bit different since it has the RAR and RAA commands that 
allow you to perform re-authorization.Wouldn't they be a nice fit?

>>>> [hannes] With the last sentence you mean that you need to have a 
>>>> way to indicate that the AAA session is terminated?
>>>> If Secure Neighbor Discovery (SEND) [RFC3971] is used by the 
>>>> devices on the network, the certificate or the information needed 
>>>> to obtain a certificate SHOULD also be sent by the AAA server to NAS.
>>>>
>>>> In point-to-point link operation, the NAS MUST identify the 
>>>> interface of MN in its request. The NAS MAY provide a prefix hint, 
>>>> e.g. of length /48 to which the AAA server MUST reply with one or 
>>>> more prefixes, e.g. of length /64.
>>>>
>>> Frank=>Tentatively, it can be the interface identifier part of 
>>> host's link local
I guess you need to describe the details of this hint a bit more.

>>
>>>>
>>>> In point-to-point operation, the AAA server MAY assign the 
>>>> prefix(es) and related parameters such as the lifetime and the 
>>>> certificates to MN from MN's profile.
>>>>
>>>> [hannes] I am not sure what this means. You mean that the AAA 
>>>> server should keep state to make sure that it does not forget what 
>>>> it has provided to the MN?
>>>> draft-sarikaya-dimeradext-prefix-auth-ps-00.txt you refer to RFC 
>>>> 4818 but I do not quite understand what you would like to see 
>>>> happening instead.
>>>>
>>>> [hannes] isn't this the same as mentioned in the previous 
>>>> requirement "AAA-based PA application MUST support the client to 
>>>> give back the prefixes to the AAA server. "
>>> Frank=>It is the same.
>>>
>>>>
>>>> renumber the prefixes authorized by AAA server. The AAA server 
>>>> SHOULD initiate prefix renumbering process. "
> don't charge based on time.  For example, $30 a month is for no 
> limited access.
>
I don't know your home setup but typically you have a DSL router at home 
and your PC / laptop may be running all the time. Your DSL router 
re-connects automatically when re-authentication is needed.

>>
>> Now, isn't it possible to re-authenticate and re-authorize the end 
>> host in case of network renumbering. Given that you have to 
>> re-authenticate quite often for other reasons as well shouldn't cause 
>> big problems.
Maybe.

When I look at the IT problems I had this year then renumbering is the 
least thing I worry about.

> However, it is probably too late after large scale deployment.
Difficult to know, I agree.

Ciao
Hannes

---

From: Frank Xia <[email-masked]>
Date: Wed, 23 Jul 2008 15:43:53 -0500

Hello Hannes

Please find my reply...

BR
Frank

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 23, 2008 3:13 PM
Subject: Re: [Dime] Relationship between 

> I agree with you that RFC 4072 combines the prefix authorization protocol 
> run with the EAP protocol run.
>
Frank=>RAR means Reauthentication or Reauthorization request.
IMHO, there should be an authentication or authorization before.
The message is still coupled with previous authentication.

Can we use the PAR/PAA without invloveing previous authentication?
I don't think so in RFC4005 context.

>>>>> prefixes from an AAA server. AAA-based PA application MUST support the 
>>>>> client to give back the prefixes to the AAA server.
>>>>>
Frank=>OK.
>>>>> lifetime of the AAA session itself? Makes things much easier. The same 
>>>>> applies a bit to this requirement: "It SHOULD be possible to renumber 
>>>>> the prefixes authorized by AAA server. The AAA server SHOULD initiate 
>>>>> prefix renumbering process. "
Frank=>IMHO,you assume that outgoing traffic trigger DSL router 
reconnection.
It is not true in some scenarios.  E.g.  if  you want to access your
home computer which is not connecting to the network,  I don't think
the DSL router can initiate re-connect.