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

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.

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

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

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

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

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

>
> 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
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
> 


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