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

[Hannes Tschofenig <[e-mail]>]

Hi Frank,

thanks for the quick feedback.

I have a few more comments inline

Frank Xia wrote:
> 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" 
> <[e-mail]>
> To: <[e-mail]>
> 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. 
>
>
Ok. We can essentially forget the other document. Right?


>> 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?
> Frank=>Prefix delegation is an authorization which may be
> decoupled from an authentication. RFC4005/4072 only deal
> 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.

>>
>> 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?
> Frank=>In IPv6 renumbering scenario, it is necessary
>
>>
>> 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?
> Frank=>IPv6 address prefix for NAS is authorized to route
>
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.
>>
>> [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.
>
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?

>>
>> 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?
> Frank=>Probably, the AAA server for prefix delegation is different from
> the AAA server for authentication.  So it is necessary to record the 
> state.
>
OK.

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

>> 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. "
> Frank=>It is the same.
>
>>
>> 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. "
> 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.
>
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.

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

Ciao
Hannes
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>>
>

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