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

[Frank Xia <[e-mail]>]

Hi Hannes

Please check my reply..

BR
Frank
----- Original Message ----- 
From: "Hannes Tschofenig" <[e-mail]>
To: "Frank Xia" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 23, 2008 2:30 PM
Subject: Re: [Dime] Relationship between 
draft-sarikaya-dimeradext-prefix-auth-ps-00.txt and 
draft-sarikaya-dime-prefix-delegation-ps-01.txt


> 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?
Frank=>Yes.

>
>
>>> 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.
Frank=>A little bit confusing.   You meant "independently " or not?

>
>>>
>>> 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?
Frank=> I can only find these now.

>
>>>
>>> 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?
Frank=>The hint is only for expressing client's preference.  The
server may honor this or not based on it's own discretion.

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

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