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

Hello Hannes

Please find my reply...

BR
Frank

----- Original Message ----- 
From: "Hannes Tschofenig" <[e-mail]>
To: "Frank Xia" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, July 23, 2008 3:13 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,
>
> 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?
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.

>
>>>
>>>>>
>>>>> 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.
Frank=>OK.
>
>>>
>>>>>
>>>>> 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.
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.

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