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,

Frank Xia wrote:
> 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?
>

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?

>>
>>>>
>>>> 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.
>
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?
>>> 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.
>
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.
> Frank=>IMHO, it is not very graceful to kick off all the users
> when renumbering.
Maybe.

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

>>
>> 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.
>
Difficult to know, I agree.

Ciao
Hannes

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