Re: [Dime] draft-sarikaya-dimeradext-prefix-auth-ps-00.txt

[Hannes Tschofenig <[e-mail]>]

Hi Behcet,

I cannot comment on Avi's and Alper's feedback. I don't participate in 
Wimax, 3GPP, and 3GPP2.

As you have seen during the meeting there wasn't support for the 
document in the room. I don't know why this is the case. There could be 
many reasons, ranging from "insufficient problem description to convince 
people" to "lack of time to help doing some work on it". This might, 
however, change as the deployment on IPv6 increases.
Hence, I wouldn't be discouraged to continue the work on your document.

Ciao
Hannes

Behcet Sarikaya wrote:
> Hi Hannes,
>   Regarding the issue of SDOs and this draft raised by Avi, I am 
> surprised by the replies from Alper as well as from Avi.
>   The fact is that this problem (AAA based prefix authorization) was 
> not brought to any SDOs by us, at least not yet. I don't know what 
> type of conclusion can be made from this, I leave it up to the working 
> group.
>   I regret the statements made by WiMAX "guru" on this issue during 
> the meeting today. I suggest that people in such positions please make 
> correct (and possibly also objective) statements and refrain from 
> confusing other people in the meeting.
>
> Regards,
>
> Behcet
>
> ----- Original Message ----
> From: Hannes Tschofenig <[e-mail]>
> To: Frank Xia <[e-mail]>
> Cc: [e-mail]
> Sent: Wednesday, July 23, 2008 3:13:21 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] <mailto:[e-mail]>>
> > To: "Frank Xia" <[e-mail] <mailto:[e-mail]>>
> > Cc: <[e-mail] <mailto:[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] <mailto:[e-mail]>>
> >>> To: <[e-mail] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dime

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