From owner-radiusext@ops.ietf.org Fri Apr 1 04:01:26 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53BD43A6808 for ; Fri, 1 Apr 2011 04:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h32Gvugol4wu for ; Fri, 1 Apr 2011 04:01:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1433D3A6806 for ; Fri, 1 Apr 2011 04:01:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5c5P-000Ff4-Rg for radiusext-data0@psg.com; Fri, 01 Apr 2011 11:00:15 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5c5N-000Fea-Bc for radiusext@ops.ietf.org; Fri, 01 Apr 2011 11:00:13 +0000 Message-ID: <4D95B038.8000706@deployingradius.com> Date: Fri, 01 Apr 2011 13:00:08 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter CC: "radiusext@ops.ietf.org" Subject: Re: Notification: draft-winter-radext-fancyaccounting-00 References: <4D9452B8.6060409@restena.lu> In-Reply-To: <4D9452B8.6060409@restena.lu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Stefan Winter wrote: > as discussed, I've written up the idea about fancy accounting in an I-D. > URL: > > https://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting/ > > Please comment if you find the time - especially those people who need > the IPv6 accounting! Nice! I have some nits on the formatting, but nothing serious. The only substantial comment is that you've defined Acct-Traffic-Class-Input-Octets, but the examples use Acct-Input-Octets, instead. Another idea would be to have the description of the flow leverage the NAS-Filter-Rule syntax. (RFC 4849). That would make it easy for everyone to describe the flows. > idnits told me that the Intended Status can't possibly be > Standards-track - RADIUS Accounting itself is only informational :-/ Well, that can be fixed somehow. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Apr 1 05:09:51 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9570E28D435 for ; Fri, 1 Apr 2011 05:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_73=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5J5oKPgo0VPe for ; Fri, 1 Apr 2011 05:09:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6A07828D3D3 for ; Fri, 1 Apr 2011 05:05:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5d4d-000ISr-HX for radiusext-data0@psg.com; Fri, 01 Apr 2011 12:03:31 +0000 Received: from g5t0007.atlanta.hp.com ([15.192.0.44]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5d4F-000IR3-5P for radiusext@ops.ietf.org; Fri, 01 Apr 2011 12:03:07 +0000 Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id 55D8314388 for ; Fri, 1 Apr 2011 12:03:04 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 1 Apr 2011 12:02:26 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Fri, 1 Apr 2011 12:02:27 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Fri, 1 Apr 2011 12:00:39 +0000 Subject: Minutes of RADEXT meeting at IETF 80 Thread-Topic: Minutes of RADEXT meeting at IETF 80 Thread-Index: AcvwZBFzWZr+6dDaQNKDVloUujyc8g== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5B555A194E@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5B555A194EGVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5B555A194EGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meeting minutes from this week's meeting below. Thanks go to Nancy for the= note taking. Note corrections are welcome. -Mauricio RADEXT WG Minutes IETF 80 Prague, Czech Republic Wednesday March 30, 2011 Meeting started 9:02AM and ended 11:27AM CEST. Approximately 17 individual= s in meeting. Chairs: Bernard Aboba Mauricio Sanchez 1. Preliminaries Audio/Video & Remote Presentation Debugging Note Well Note Takers - Note volunteer Nancy Cam-Winget Jabber scribe - Stefan W. jabber scribe - Dan Romanascu asks for the floor for 1 min: Intervenes to announce that B= ernard is now IAB Chair. As a result, he needs to release some responsibil= ity. Dan recognizes his work in radext and thanks him for his contribution= s. So, now as a result, there is an open process to find a co-chair to wor= k with Mauricio. Bernard will help while transition occurs. If interested= or have questions, can approach Dan or Bernard to learn about what the job= entails. Agenda bash - review of IPv6, then security work items and wrapup. There was a request= to move one of the presos due to meeting conflicts. Document Status -2 publications: status-server and design guidelines -1 in RFC queue: radius over TCP -3 completed WGLC * New tunnel types values: Pending IANA resolution * IPv6 RADIUS attributes: open issues * crypto-agility: open issues 2. IANA issues A. How to allocate tunnel params? In RFC 3575 (RFC2868 conflicts as 3575= assigns based on expert review but didn't update 2868). Omission of RFC 2= 868 could be an errata; this is basically a request for metadata. - Asks Dan for comment: was looking for input from the working group before= proceeding. - Alan thought it was an errata. - Stefan states no opinion. - Klaas also states no opinion. - Nancy asks for further understanding. Bernard clarifies: RFC 2868 states = "standards action" and 3575 is more lenient in saying just expert review. - Now Dan remembers: when there's conflicts such as this, 2 solutions: take= the stricter or take the latest. But if it's the latest, then it needs to = be clearer. Believes in this case, explicit clarification is justified sin= ce 3575 is more recent and the request is justified. But need IESG perspec= tive review by WG. - Bernard suggests to get a sense of this group and then take it to the mai= lgroup. Asks: proposal is to accept and verify the errata and update 3575 = to include 2868. In favor: 10, non oppose. Given consensus, will take to = the mail list. B. Request for registration for NAS-port-type. Under 3575, falls under = expert review. This request is for NAS-port-type relating to WiMax - Stefan comments that there's already type for WiFi so not sure why anothe= r one is needed, just one. - Klaas comments that agrees with Stefan's comments. - Nancy comments that looking at the current assignment is that there is on= ly 1 allocation per mode. - Bernard takes the general comment of only allocating one as the response = to take back to the request. Given consensus here, will verify that opinio= n in the reflector. 3. RADIUS Attributes for 6rd, Sheng Jiang http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib - 6rd used to provide IPv6 connectivity svcs thru IPv4....there's a working= group draft. In some scenarios, the access gateway acts as access gateway= of users. So user config info can be managed by AAA servers (between AAA = and BNG, RADIUS is used to carry the info). New attributes are needed to p= ropagate this info. - Proposal to add a IPv6-6rd-config attribute. A draft was presented by th= e Softwire WG and accepted as a working group iten in the Beijing meeting. = Also added request to RADEXT WG maillist. Received good comments to name = the attribute, fix the error on counting length (acknowledges Alan DeKok ).= The Softwire WG is ready for last call after this meeting, so if there's = more feedback by radext then we can move forward. - Bernard asks how many IPv4 address can be included? And how do you know = how many are there? Response: can know counted based on the length. Berna= rd comments that AVP are typically fixed length, this request is a dynamic = length. Other question is can we have many of these attributes? - Nancy asks on clarify on fixed length vs. dynamic length. Bernard clarif= ies that there are two ways to do this, but one issue is how to map the 6rd= prefix. - Alan says can do this through extended attributes. - Bernard comments that it's a question of timing. - Nancy says that would build a dependency on the extended attributes. - Alan and Bernard agrees. - Bernard notes that we can ask for a review again. 4. RADIUS Issues in IPv6 Deployments, Jacni Qin http://tools.ietf.org/html/draft-hu-v6ops-radius-issues-ipv6 Thanks Bernard for helping find the right WG to bring the issues - Issues encountered: 1st is identifying users on diff protocols. That is, = hard to characterize after user authN whether the authZ for v4 or v6 - 2nd issue: network or host on customer premises - 3rd issue: protocol specific accounting - Possible solution: * Use vendor specific attributes to solve all problems but lacks interop. * Can have special implementations of NAS to addres issue 1 and 2. Set seve= ral domains on NAS like "v4, v6 or dual stack" with "framed host, or home n= etwork" then require users to attach the addition info (like @domain) when = sending the request. * Asks the WG for advice. Would like to define new attributes to solave al= l issues....for the 3rd issue, to address "framed" services like 'acct-fram= ed-ipv4-input/output-*' * Asks if it can be adopted as an informational document? And if so, what's= the right approach? * Bernard discusses, orginal 3162 only handles a specific set (PPP access) = of IPv6, then added prefix delegation. There's another draft to deal with o= ther scenarios (like dsl and wlan)....and expanding (like 6rd) and expandin= g attributes as IPv6 deployments come to light. Part of the problem is 3162= only addresses one scenario....so are the existing definitions used to fit= the new scenarios? Suggests that we hold on as we will be discussing issu= e #2 later in this session. But for issue #1 asks Alan on the accounting i= ssue, with adding IPv6. Alan comments that the attributes are global, there= was a thread before; in 2866 don't have anything to do with IPv4 other tha= n getting an IPv4 address in the packet. So, what do you do when user has m= ultiple IP addresses? Given specs are silent, there are diff implementation= s. Bernard agrees.acct info is for all of the user's traffic but "what that= means" is based on the implementation. * Jouni Kohren comments: in mobile network, there's a similar situation. Th= ey use what is done today, but there are also other attributes to tell the = service type based on that authZ happens. At least for mobile networks its= similar and we have used what's there using vendor AVPs. * Bernard asks: how do you handle the accounting packets? Jouni responds: = based on time.but it's really a don't care if its v4 or v6. * Bernard suggests another way to do the accounting if want to separate v4 = or v6 but Jacni says its too tricky. * Jacni suggests that perhaps we allocate one new attribute for "framed" se= rvice? * Stefan wonders whether that would lead? As RADIUS doesn't look at distinc= tions (e.g no wired vs wireless), and this is doing it at the IP layers and= concerned that it may require too many new attributes * Jacni suggests can we just do the "framed" services? * Alan also expresses similar concerns to Stefan's comments. There's anoth= er scenario that uses multiple sessionID to track the multiple flows as opp= osed to allocating new attributes * Bernard understands multi-session id, but how to distinguish v4 vs v6? * Alan says session ID would also have the ipv4 addressing and correlate th= e multi-session ID to correlate the 2 sessions (1 being v4 and 2nd v6). * Leaf (Huawei) comments on technical report that is also looking at the tr= acking for the same session that has 2 traffic flows. The access server has= separate queues one for each v4 vs. v6....that means the access server sho= uld have the ability of providing the distinct information to report to the= AAA server and allow for different accounting policies. * Bernard: question to the floor was whether we should take this as a WG it= em? So, should issue 3 be a WG to solve this problem? * Leaf comments that question is whether we can take this informational? J= acni says its OK * Bernard wants to take the question: should we work on issue #3? 2 in fav= or, none against. Alan has no opinion * Stefan comments that what could be done is to specify it in a general way= so that detailed reports could be sent (against doing it just for v4 and v= 6 attributes). * Bernard thinks there's some interest.so we can take it on in the mail lis= t and figure out how to move forward. * Jacni comments that understands Stefan's concern but it is a high priorit= y item to them. * Bernard understands that we have a short timeframe especifally for v6. * Stefan suggests that a VSA can be used until a proper solution is in plac= e. * Jouni suggests to use VSA too. * Bernard closes by stating it will go to the mail list. 5.RADIUS Attributes for Dual Stack Access, L. Yeh http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access - Notes that draft is updated to -02, idea is roughly the same - This proposal helps address Jacni's issue but also questions whether othe= r attributes beyond the traffic count are needed. - Suggests there's another deployment scenario whereby you want to allow th= e operator (e.g. AAA server) for the type of user (e.g. dual stack, v4 only= , v6 only). - Proposes a list of User-Type values for handling service distinctions. - Bernard thanks for the comprehensive list. Notes another distinction of = how the routing goes from the nas to the cpe. There's also the framed-ipv6= route proposed which is what the nas advertises to the cpe. - Leaf notes that it's not about the route, this is about the accounting. - Asks if IPoE needs another set of codes? And similarly adding attributes = on the NAS-Port-Type or Framed-Protocol (with IPoE). - Mentions traffic statistic attribute values may be needed as well and pro= poses a new set for the use of dual stack. - Closes on whether these should be taken on as a WG item. - Stefan comments regarding the accounting express concern on the prolifera= tion of the different attributes. - Leaf states that the accounting is for per user. - Bernard asks if further comments? Notes that we agreed to look at statis= tics, but on the user-types don't need an explicit type as there's a way to= distinguish today, we may need to have means to distinguish NAS types. But= am not sure that we want another draft that discusses existing things alre= ady, so another one can cause further confusion. - Leaf counters that we need to solve current issues as operators need to c= hange the type of use (user-type), so we need AAA server to tell access ser= ver the user-type. - Bernard comments that there should already be a mechanism to help do that= . - Nancy asks is it just using the current attributes to distinguish the us= er type - Leaf wants new attributes to tell what kind of user it is. - Stefan points that current inspection of the current attributes already a= ssigned, then one can uniquely define the user type. - Bernard comments that the attributes today are already used to assign the= service. - Leaf comments that the NAS only has the pool names, want the AAA server t= o just tell the NAS the user type - Bernard is confused on what attributes are needed. - Stefan understands that AAA server doesn't give out the pool, just indica= tion to NAS a prefix, it doesn't have the framed attributes. - Bernard clarifies that server doesn't have the pool....and the pool name = should already map between NAS and AAA server. Suggests that we should bri= ng it to the list as we agreed to work on the accounting part, but we need = to better understand on what is missing to require the user type. 6. RADIUS Attributes for IPv6 Access Networks, W. Dec http://tools.ietf.org/html/draft-ietf-radext-ipv6-access - Bernard notes that we need a bit or work to resolve Wojciech's issue. Sl= ides are present, so Bernard reviews them: - Bernard describes problem: 3162 defines framed-ipv6-route, in 2865 also h= as framed-route (for ipv4) and framed-routing to describe options for how I= GP should behave. 3162 doesn't define the *-routing. - There doesn't seem to have an implication that IGP has been enabled...316= 2 defines route-ipv6-information attributes. Request is to clarify differe= nce between framed-ipv6-route and route-ipv6-information attribute. - Bernard asks if there are implementations of this so we can understand wh= at is actually done today? - Leaf asks which RFC? Bernard notes its 3162 that defines framed-ipv6-rout= e - This is the only issue holding up the RFC, so Bernard wants to gets this = resolved so that we can move forward without causing interop problems. - Bernard solicits input.none is provided - Jouni mentions that they've implemented IPv6 but ignore these attributes.= Bernard asks what info is provided to the RA? They do use the framed-ipv6= -prefix to the gateway....Bernard agrees that it would make sense. - RFC4191 is more specific routes draft.Bernard asks Jouni if they implemen= t today? Answer: no - Leaf comments 3162 has a different format for the route-ipv6-information.= The first only has a text string, the purpose may be the same, but the for= mats are different. So, the new draft could specify the prefix. - Bernard would like to claim that framed-ipv6-route has the same goals as = framed-route. The new attribute is for the more specific route while the ot= her is for IGP. Will bring this to the list to get consensus. 7. Crypto-Agility Requirements for RADIUS, Bernard Aboba http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements - Document to capture requirements and requests for review in TRAC to close= on this asap - Open issue 89: keywrap and password hiding requirements - If RADIUS is protected as a whole, is keywrap needed? - Stefan: is this an end to end keywrap vs. proxy? - Bernard believes it is hop by hop. - Stefan: if its end to end then there may be more benefit than if its just= hop by hop. - Bernard: confidentiality was not a requirement, so its possible that not = the whole packet is encrypted, so keywrap would be needed. So, we would wa= nt to keep this and clarify it in the doc. - Dan asks if there's a discussion on keywrap in future work? Since there's= Glen's draft as informational that perhaps we should move to standards spa= ce? Bernard comments that its in the queue so it's there. - Bernard suggests that we can do the writeup to state that if RADIUS is pr= otected, then keywrap is not needed; but if there's no protection then keyw= rap can be used. - Dan states that it makes sense, but need communication to the IESG that t= his is the resolution - Issue 90: process for publication and selection - Proposal is to define process through experimental drafts to define the m= echanisms that can be used. - With these 2 resolved, then it can go to final WGLC. 8. RADIUS over TLS, Stefan Winter http://tools.ietf.org/html/draft-ietf-radext-radsec - New draft submitted to address open issues except for "client id" - Everything goes thru one port - Auth server, acct server and dynauth server are separate entities - Client ID is hard as different modes need different treatment: PSK vs X.5= 09 fingerprint vs. X.509 proper (e.g. full chain, OCSP verification) - In RADIUS/UDP, client id =3D authZ used to exchange packets - For RADIUS/TLS-PSK: there can be more than 1 NAS talking - Biggest diff where client id !=3D authZ because the X.509 clients are uni= que identified by the issuer/serial number. So, can have authZ based on cli= ent types.can have that info in the cert data (policyOID) or out-certificat= e (query to some directory) - Bernard comments that it would be useful to communicate an error to deter= mine unauthorized certificate. Stefan: in this case, the connection would = just close. Bernard suggests that TLS error messages could also be used. = Stefan comments that he can look into it - Consequence to the spec: * Stack needs to expose ID criteria to admin: issuer/serial number * Need to add text/guidelines for AuthZ - Bernard suggests looking at "tls server id check" from Peter St Andre as = it relates to the dynamic discovery draft for how to delegate a server to a= domain and verify the trust. Also talks about other attributes that should= be looked at - Stefan would like to keep it simple by, say, looking at serial number onl= y - Dan speaking as contributor: there are many places in IETF discussing ide= ntities or places that can be looked at to get identity information. Don't= know if and how whether the problem can be solved consistently given that = there's no single model.but would like to point out that there are other pl= aces in IETF that also have this problem and may have ideas to use - Stefan notes that this document is still experimental and would like to l= ook at how industry currently looks and uses certificates - Given that there are more than 1 NAS as a potential, there's the question= of how a client ID can be used. 9. Dynamic Peer Discovery, Stefan Winter http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery - No new revision since last draft - Given that there are 3 separate entities, 3 labels are needed for auth, a= cct and dynauth - Could look like: S-NAPTRs: radius.tls, radacct.tls, raddynauth.tls - As a result can now generate a new draft - Jouni notes that there is a similar draft in DIAMETER that is going to IE= SG. Is this draft aligned with the one in DIAMETER? - Stefan notes that we are limited to 3. - Jouni notes that since there's nothing official in diameter, will there b= e 2 different or can we keep them the same? - Stefan notes that they are slightly different. Though radius could just u= se "aaa" with no extension 10. RADIUS over DTLS, Alan DeKok http://tools.ietf.org/html/draft-ietf-radext-dtls - No real changes since last IETF.current draft may be expired so need to u= pdate it - Open issues: need to resync with RTLS draft, double check consistency. Po= rt reuse issues, want review from Stig Venaas regarding the radsecproxy - There are 3 implementations radsecproxy, jradius, freeradius - Main dependency is the rtls sync - Stefan notes that the port number had been resolved to only use 1 port. A= lan agrees, just notes that the draft needs to be updated to reflect the ne= w outcome 11. RADIUS Protocol Extensions, Alan DeKok http://tools.ietf.org/html/draft-ietf-radext-radius-extensions - Almost same presentation as IETF 79.this has been discussed for many year= s - Review of current proposal: change 1 byte; take 1 byte from value to exte= nd type. Description of the new format to allow for 1.5K new attributes, al= low grouping via TLS, standard way to having "long" attrs and new means for= allowing vendors to have long VSA - Bernard notes that this kind of issue has arisen for a while now and the = hope that this one is more palatable to push forward. Need to bring it to = people who want it. - Stefan notes that when working on accounting and such those would be a go= od candidate for grouping them per this proposal. - Bernard notes that this may be good incentive to get the ones requesting = for new attributes to use this new way. - Mauricio comments that if we want people to use this, we need to wrap thi= s one up first so that we can then get the proposals for new attribute allo= cation to use this new format. - Bernard states that there were some that still did not want to use this..= .would be better if they would sign up willingly - Alan suggests that any new specs coming out, would be inclined to push th= em hard to use this - About 7 people have read the draft - Dan comments that it is useful, but at this point can not make it a shows= topper on other proposals until this document has been ratified. 12. Discussion and Wrap-up - Due to several topics running over, there was no time left to review next= steps. Chairs commented that several action items had been identified and= would be driven from the meeting notes. --_000_9BC2F7926B33FE4AB10D69891D58FC1C5B555A194EGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Meeting minute= s from this week’s meeting below.  Thanks go to Nancy for the no= te taking. 

Note corrections are welcome.

-Mauricio

 

 

 

RADEXT WG Minutes=

IETF 80

Prague, Czech Republic

Wednesday Ma= rch 30, 2011

Meeting started 9:02AM and = ended 11:27AM CEST.  Approximately 17 individuals in meeting.

 

Chair= s:  Bernard Aboba <bernard_aboba@hotmail.com>

       &n= bsp;        Mauricio Sanchez <ma= uricio.sanchez@hp.com>

 

1. Preliminari= es

Audio/Video & Remote Presentatio= n Debugging

Note Well

Note Takers

- Note volu= nteer Nancy Cam-Winget

Jabber scribe

- Stefan W. jabber scribe

 

- Dan Romanasc= u asks for the floor for 1 min: Intervenes to announce that Bernard is now = IAB Chair.  As a result, he needs to release some responsibility. = ; Dan recognizes his work in radext and thanks him for his contributions.&n= bsp; So, now as a result, there is an open process to find a co-chair to wo= rk with Mauricio.  Bernard will help while transition occurs.  If= interested or have questions, can approach Dan or Bernard to learn about w= hat the job entails.

 

Agenda bash

- rev= iew of IPv6, then security work items and wrapup.  There was a request= to move one of the presos due to meeting conflicts.

 

Document Status=

-2 publications: status-server and design gu= idelines

-1 in RFC queue: radius over TC= P

-3 completed WGLC

* New tunnel types values: Pending IANA resolution

* IPv6 RADIUS attributes: open issues<= /p>

* crypto-agility: open issues

 

2. IANA issues=

A.    How to allocate tunnel = params? In RFC 3575 (RFC2868 conflicts as 3575 assigns based on expert revi= ew but didn’t update 2868).  Omission of RFC 2868 could be an er= rata; this is basically a request for metadata. 

- Asks Dan for comment: was looking for input from the worki= ng group before proceeding. 

- Ala= n thought it was an errata.

- Stefan sta= tes no opinion.

- Klaas also states no o= pinion.

- Nancy asks for further underst= anding. Bernard clarifies: RFC 2868 states “standards action” a= nd 3575 is more lenient  in saying just expert review.

=

- Now Dan remembers: when there’s conflicts such= as this, 2 solutions: take the stricter or take the latest. But if it̵= 7;s the latest, then it needs to be clearer.  Believes in this case, e= xplicit clarification is justified since 3575 is more recent and the reques= t is justified.  But need IESG perspective review by WG.

- Bernard suggests to get a sense of this group and t= hen take it to the mailgroup.  Asks: proposal is to accept and verify = the errata and update 3575 to include 2868.  In favor: 10, non oppose.=   Given consensus, will take to the mail list.

 

B.   = Request for registration for NAS-port-type.  Under 3575, falls under = expert review.  This request is for NAS-port-type relating to WiMax

- Stefan comments that there’s alrea= dy type for WiFi so not sure why another one is needed, just one.

- Klaas comments that agrees with Stefan’s = comments.

- Nancy comments that looking = at the current assignment is that there is only 1 allocation per mode.=

- Bernard takes the general comment of only = allocating one as the response to take back to the request.  Given con= sensus here, will verify that opinion in the reflector.

 

 =

3. RADIUS Attributes for 6rd, Sheng Jiang

http://tools.ietf.org/html/draft-ietf-softwire-= 6rd-radius-attrib

- 6rd used to provide = IPv6 connectivity svcs thru IPv4….there’s a working group draft= .  In some scenarios, the access gateway acts as access gateway of use= rs.  So user config info can be managed by AAA servers (between AAA an= d BNG, RADIUS is used to carry the info).  New attributes are needed t= o propagate this info.

- Proposal to add= a IPv6-6rd-config attribute.  A draft was presented by the Softwire W= G and accepted as a working group iten in the Beijing meeting.  Also a= dded request to RADEXT WG maillist.  Received good comments to name th= e attribute, fix the error on counting length (acknowledges Alan DeKok ).&n= bsp; The Softwire WG is ready for last call after this meeting, so if there= ’s more feedback by radext then we can move forward.

- Bernard asks how many IPv4 address can be included?&nb= sp; And how do you know how many are there?  Response: can know counte= d based on the length.  Bernard comments that AVP are typically fixed = length, this request is a dynamic length.  Other question is can we ha= ve many of these attributes?

- Nancy ask= s on clarify on fixed length vs. dynamic length.  Bernard clarifies th= at there are two ways to do this, but one issue is how to map the 6rd prefi= x.

- Alan says can do this through exten= ded attributes.

- Bernard comments that = it’s a question of timing. 

= - Nancy says that would build a dependency on the extended attributes.

- Alan and Bernard agrees.

- Bernard notes that we can ask for a review again.=

 

4.= RADIUS Issues in IPv6 Deployments, Jacni Qin

http://tools.ietf.org/html/draft-hu-v6ops-radius-issues-ipv6

Thanks Bernard for helping find the right WG to= bring the issues

- Issues encountered: = 1st is identifying users on diff protocols. That is, hard to characterize a= fter user authN whether the authZ for v4 or v6

- 2nd issue: network or host on customer premises

- 3rd issue: protocol specific accounting

- Possible solution:

= * Use vendor specific attributes to solve all problems but lacks interop.

* Can have special implementations of NAS= to addres issue 1 and 2. Set several domains on NAS like “v4, v6 or = dual stack” with “framed host, or home network” then requ= ire users to attach the addition info (like @domain) when sending the reque= st.

* Asks the WG for advice.  Woul= d like to define new attributes to solave all issues….for the 3rd iss= ue, to address “framed” services like ‘acct-framed-ipv4-i= nput/output-*’

* Asks if it can be= adopted as an informational document? And if so, what’s the right ap= proach?

* Bernard discusses, orginal 316= 2 only handles a specific set (PPP access) of IPv6, then added prefix deleg= ation. There’s another draft to deal with other scenarios (like dsl a= nd wlan)….and expanding (like 6rd) and expanding attributes as IPv6 d= eployments come to light. Part of the problem is 3162 only addresses one sc= enario….so are the existing definitions used to fit the new scenarios= ?  Suggests that we hold on as we will be discussing issue #2 later in= this session.  But for issue #1 asks Alan on the accounting issue, wi= th adding IPv6. Alan comments that the attributes are global, there was a t= hread before; in 2866 don’t have anything to do with IPv4 other than = getting an IPv4 address in the packet. So, what do you do when user has mul= tiple IP addresses? Given specs are silent, there are diff implementations.= Bernard agrees.acct info is for all of the user’s traffic but “= ;what that means” is based on the implementation.

* Jouni Kohren comments: in mobile network, there’s a= similar situation. They use what is done today, but there are also other a= ttributes to tell the service type based on that authZ happens.  At le= ast for mobile networks its similar and we have used what’s there usi= ng vendor AVPs.

* Bernard asks: how do y= ou handle the accounting packets?  Jouni responds:  based on time= .but it’s really a don’t care if its v4 or v6.

* Bernard suggests another way to do the accounting if w= ant to separate v4 or v6 but Jacni says its too tricky.

* Jacni suggests that perhaps we allocate one new attribute= for “framed” service?

* Ste= fan wonders whether that would lead? As RADIUS doesn’t look at distin= ctions (e.g no wired vs wireless), and this is doing it at the IP layers an= d concerned that it may require too many new attributes

* Jacni suggests can we just do the “framed” se= rvices?

* Alan also expresses similar co= ncerns to Stefan’s comments.  There’s another scenario tha= t uses multiple sessionID to track the multiple flows as opposed to allocat= ing new attributes

* Bernard understands= multi-session id, but how to distinguish v4 vs v6?

* Alan says session ID would also have the ipv4 addressing and= correlate the multi-session ID to correlate the 2 sessions (1 being v4 and= 2nd v6).

* Leaf (Huawei) comments on te= chnical report that is also looking at the tracking for the same session th= at has 2 traffic flows. The access server has separate queues one for each = v4 vs. v6….that means the access server should have the ability of pr= oviding the distinct information to report to the AAA server and allow for = different accounting policies.

* Bernard= : question to the floor was whether we should take this as a WG item? = So, should issue 3 be a WG to solve this problem?

* Leaf comments that question is whether we can take this info= rmational?  Jacni says its OK

* Ber= nard wants to take the question: should we work on issue #3?  2 in fav= or, none against. Alan has no opinion

* = Stefan comments that what could be done is to specify it in a general way s= o that detailed reports could be sent (against doing it just for v4 and v6 = attributes).

* Bernard thinks there̵= 7;s some interest.so we can take it on in the mail list and figure out how = to move forward.

* Jacni comments that u= nderstands Stefan’s concern but it is a high priority item to them.

* Bernard understands that we have a shor= t timeframe especifally for v6.

* Stefan= suggests that a VSA can be used until a proper solution is in place.<= /o:p>

* Jouni suggests to use VSA too.

* Bernard closes by stating it will go to the mail l= ist.

 

 

5.RADIUS Attributes for Du= al Stack Access, L. Yeh

http://tools.ie= tf.org/html/draft-yeh-radext-dual-stack-access

- Notes that draft is updated to -02, idea is roughly the same<= /o:p>

- This proposal helps address Jacni’s i= ssue but also questions whether other attributes beyond the traffic count a= re needed.

- Suggests there’s anot= her deployment scenario whereby you want to allow the operator (e.g. AAA se= rver) for the type of user (e.g. dual stack, v4 only, v6 only).<= /p>

- Proposes a list of User-Type values for handling = service distinctions.

- Bernard thanks f= or the comprehensive list.  Notes another distinction of how the routi= ng goes from the nas to the cpe.  There’s also the framed-ipv6 r= oute proposed which is what the nas advertises to the cpe.

- Leaf notes that it’s not about the route, this i= s about the accounting.

- Asks if IPoE n= eeds another set of codes? And similarly adding attributes on the NAS-Port-= Type or Framed-Protocol (with IPoE).

- M= entions traffic statistic attribute values may be needed as well and propos= es a new set for the use of dual stack.

= - Closes on whether these should be taken on as a WG item.

- Stefan comments regarding the accounting express conce= rn on the proliferation of the different attributes.

- Leaf states that the accounting is for per user.<= /p>

- Bernard asks if further comments?  Notes tha= t we agreed to look at statistics, but on the user-types don’t need a= n explicit type as there’s a way to distinguish today, we may need to= have means to distinguish NAS types. But am not sure that we want another = draft that discusses existing things already, so another one can cause furt= her confusion.

- Leaf counters that we n= eed to solve current issues as operators need to change the type of use (us= er-type), so we need AAA server to tell access server the user-type.

- Bernard comments that there should already b= e a mechanism to help do that.

- Nancy a= sks is it just  using the current attributes to distinguish the user t= ype

- Leaf wants new attributes to tell = what kind of user it is.

- Stefan points= that current inspection of the current attributes already assigned, then o= ne can uniquely define the user type.

- = Bernard comments that the attributes today are already used to assign the s= ervice.

- Leaf comments that the NAS onl= y has the pool names, want the AAA server to just tell the NAS the user typ= e

- Bernard is confused on what attribut= es are needed.

- Stefan understands that= AAA server doesn’t give out the pool, just indication to NAS a prefi= x, it doesn’t have the framed attributes.

- Bernard clarifies that server doesn’t have the pool….= and the pool name should already map between NAS and AAA server.  Sugg= ests that we should bring it to the list as we agreed to work on the accoun= ting part, but we need to better understand on what is missing to require t= he user type.

 

6. RADIUS Attributes for IPv6 Access Networks, W. Dec =

http://tools.ietf.org/html/draft-ietf-radext= -ipv6-access

- Bernard notes that we nee= d a bit or work to resolve Wojciech’s issue.  Slides are present= , so Bernard reviews them:

- Bernard des= cribes problem: 3162 defines framed-ipv6-route, in 2865 also has framed-rou= te (for ipv4) and framed-routing to describe options for how IGP should beh= ave. 3162 doesn’t define the *-routing.

- There doesn’t seem to have an implication that IGP has been e= nabled…3162 defines route-ipv6-information attributes.  Request = is to clarify difference between framed-ipv6-route and route-ipv6-informati= on attribute.

- Bernard asks if there ar= e implementations of this so we can understand what is actually done today?=

- Leaf asks which RFC? Bernard notes it= s 3162 that defines framed-ipv6-route

- = This is the only issue holding up the RFC, so Bernard wants to gets this re= solved so that we can move forward without causing interop problems.

- Bernard solicits input.none is provided=

- Jouni mentions that they’ve implemen= ted IPv6 but ignore these attributes. Bernard asks what info is provided to= the RA?  They do use the framed-ipv6-prefix to the gateway….Ber= nard agrees that it would make sense.

- = RFC4191 is more specific routes draft.Bernard asks Jouni if they implement = today?  Answer: no

- Leaf comments = 3162 has a different format for the route-ipv6-information. The first only = has a text string, the purpose may be the same, but the formats are differe= nt.  So, the new draft could specify the prefix.

- Bernard would like to claim that framed-ipv6-route has the = same goals as framed-route. The new attribute is for the more specific rout= e while the other is for IGP.  Will bring this to the list to get cons= ensus.

 

7. Crypto-Agility Requirements for RADIUS, Bernard Aboba

http://tools.ietf.org/html/draft-ietf-radext-cry= pto-agility-requirements

- Document to c= apture requirements and requests for review in TRAC to close on this asap

- Open issue 89: keywrap and password hid= ing requirements

- If RADIUS is protecte= d as a whole, is keywrap needed?

- Stefa= n: is this an end to end keywrap vs. proxy?

- Bernard believes it is hop by hop.

- Stefan: if its end to end then there may be more benefit than if its jus= t hop by hop.

- Bernard: confidentiality= was not a requirement, so its possible that not the whole packet is encryp= ted, so keywrap would be needed.  So, we would want to keep this and c= larify it in the doc.

- Dan asks if ther= e’s a discussion on keywrap in future work? Since there’s Glen&= #8217;s draft as informational that perhaps we should move to standards spa= ce?  Bernard comments that its in the queue so it’s there.<= /o:p>

- Bernard suggests that we can do the writeup= to state that if RADIUS is protected, then keywrap is not needed; but if t= here’s no protection then keywrap can be used.

- Dan states that it makes sense, but need communication to th= e IESG that this is the resolution

- Iss= ue 90: process for publication and selection

- Proposal is to define process through experimental drafts to define = the mechanisms that can be used.

- With = these 2 resolved, then it can go to final WGLC.

 

8. RADIUS over TLS, Stefa= n Winter

http://tools.ietf.org/html/dra= ft-ietf-radext-radsec

- New draft submi= tted to address open issues except for “client id”

- Everything goes thru one port

- Auth server, acct server and dynauth server are separate e= ntities

- Client ID is hard as different= modes need different treatment: PSK vs X.509 fingerprint vs. X.509 proper = (e.g. full chain, OCSP verification)

- I= n RADIUS/UDP, client id =3D authZ used to exchange packets

- For RADIUS/TLS-PSK: there can be more than 1 NAS talki= ng

- Biggest diff where client id !=3D a= uthZ because the X.509 clients are unique identified by the issuer/serial n= umber. So, can have authZ based on client types.can have that info in the c= ert data (policyOID) or out-certificate (query to some directory)

- Bernard comments that it would be useful to com= municate an error to determine unauthorized certificate.  Stefan: in t= his case, the connection would just close.  Bernard suggests that TLS = error messages could also be used.  Stefan comments that he can look i= nto it

- Consequence to the spec:

* Stack needs to expose ID criteria to admin: = issuer/serial number

* Need to add text= /guidelines for AuthZ

- Bernard suggests= looking at “tls server id check” from Peter St Andre as it rel= ates to the dynamic discovery draft for how to delegate a server to a domai= n and verify the trust. Also talks about other attributes that should be lo= oked at

- Stefan would like to keep it s= imple by, say, looking at serial number only

- Dan speaking as contributor: there are many places in IETF discussin= g identities or places that can be looked at to get identity information.&n= bsp; Don’t know if and how whether the problem can be solved consiste= ntly given that there’s no single model.but would like to point out t= hat there are other places in IETF that also have this problem and may have= ideas to use

- Stefan notes that this d= ocument is still experimental and would like to look at how industry curren= tly looks and uses certificates

- Given = that there are more than 1 NAS as a potential, there’s the question o= f how a client ID can be used.

&nbs= p;

9. Dynamic Peer Discovery, Stefan Winter

http://tools.ietf.org/html/draft-ietf-rad= ext-dynamic-discovery

- No new revision = since last draft

- Given that there are = 3 separate entities, 3 labels are needed for auth, acct and dynauth

- Could look like: S-NAPTRs: radius.tls, radacc= t.tls, raddynauth.tls

- As a result can = now generate a new draft

- Jouni notes t= hat there is a similar draft in DIAMETER that is going to IESG. Is this dra= ft aligned with the one in DIAMETER?

- S= tefan notes that we are limited to 3.

- = Jouni notes that since there’s nothing official in diameter, will the= re be 2 different or can we keep them the same?

- Stefan notes that they are slightly different. Though radius coul= d just use “aaa” with no extension

 

10. RADIUS over DTLS, Alan= DeKok

http://tools.ietf.org/html/draft-= ietf-radext-dtls

- No real changes since= last IETF.current draft may be expired so need to update it

=

- Open issues: need to resync with RTLS draft, double = check consistency. Port reuse issues, want review from Stig Venaas regardin= g the radsecproxy

- There are 3 implemen= tations radsecproxy, jradius, freeradius

- Main dependency is the rtls sync

- St= efan notes that the port number had been resolved to only use 1 port. Alan = agrees, just notes that the draft needs to be updated to reflect the new ou= tcome

 

11. RADIUS Protocol Extensions, Alan DeKok

http://tools.ietf.org/html/draft-ietf-radext-radius-extensions=

- Almost same presentation as IETF 79.t= his has been discussed for many years

- = Review of current proposal: change 1 byte; take 1 byte from value to extend= type. Description of the new format to allow for 1.5K new attributes, allo= w grouping via TLS, standard way to having “long” attrs and new= means for allowing vendors to have long VSA

- Bernard notes that this kind of issue has arisen for a while now and= the hope that this one is more palatable to push forward.  Need to br= ing it to people who want it.

- Stefan n= otes that when working on accounting and such those would be a good candida= te for grouping them per this proposal.

= - Bernard notes that this may be good incentive to get the ones requesting = for new attributes to use this new way.

= - Mauricio comments that if we want people to use this, we need to wrap thi= s one up first so that we can then get the proposals for new attribute allo= cation to use this new format.

- Bernard= states that there were some that still did not want to use this…woul= d be better if they would sign up willingly

- Alan suggests that any new specs coming out, would be inclined to pus= h them hard to use this

- About 7 people= have read the draft

- Dan comments that= it is useful, but at this point can not make it a showstopper on other pro= posals until this document has been ratified.

 

 

12. Discussion and Wrap-up

- Due to several topics running over, there was no time left to review ne= xt steps.  Chairs commented that several action items had been identif= ied and would be driven from the meeting notes.

= = --_000_9BC2F7926B33FE4AB10D69891D58FC1C5B555A194EGVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Apr 1 11:19:45 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49563A68C1 for ; Fri, 1 Apr 2011 11:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i9CkJuelRV2 for ; Fri, 1 Apr 2011 11:19:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D297F3A686C for ; Fri, 1 Apr 2011 11:19:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5ivT-0009SN-V2 for radiusext-data0@psg.com; Fri, 01 Apr 2011 18:18:27 +0000 Received: from remote.iea-software.com ([70.89.142.196] helo=aspen.internal.iea-software.com) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5ivR-0009SD-A4 for radiusext@ops.ietf.org; Fri, 01 Apr 2011 18:18:25 +0000 Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id for ; Fri, 1 Apr 2011 11:18:23 -0700 Date: Fri, 1 Apr 2011 11:18:15 -0700 (Pacific Daylight Time) From: Peter Deacon To: "'radiusext@ops.ietf.org'" Subject: 6rd attribute compromise? In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5B555A194E@GVW0671EXC.americas.hpqcorp.net> Message-ID: References: <9BC2F7926B33FE4AB10D69891D58FC1C5B555A194E@GVW0671EXC.americas.hpqcorp.net> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="763195077-18522-1301676194=:2688" Content-ID: Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --763195077-18522-1301676194=:2688 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 1 Apr 2011, Sanchez, Mauricio (HP Networking) wrote: > 3. RADIUS Attributes for 6rd, Sheng Jiang > http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib > - Bernard asks how many IPv4 address can be included? And how do you > know how many are there? Response: can know counted based on the > length. Bernard comments that AVP are typically fixed length, this > request is a dynamic length. Other question is can we have many of these > attributes? > - Nancy asks on clarify on fixed length vs. dynamic length. Bernard > clarifies that there are two ways to do this, but one issue is how to > map the 6rd prefix. > - Alan says can do this through extended attributes. > - Bernard comments that it¢s a question of timing. > - Nancy says that would build a dependency on the extended attributes. > - Alan and Bernard agrees. As a compromise any thoughts about defining stand-ins for what are essentially TLVs to remove external dependencies? Upside future implementations supporting TLVs *may* be able to more broadly support the 6rd configuration attribute. Downside at least 7 more bytes for this attribute, more work to manage additional static fields. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SubType (1) | SubLen (3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4MaskLen | SubType (2) | SubLen (20) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6rdPrefixLen | 6rdPrefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubType (3) | SubLen (6) |6rdBRIPv4Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ regards, Peter --763195077-18522-1301676194=:2688-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Apr 1 23:34:18 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996943A6A48 for ; Fri, 1 Apr 2011 23:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTGvof43DvA7 for ; Fri, 1 Apr 2011 23:34:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9DD1F3A6A43 for ; Fri, 1 Apr 2011 23:34:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5uOE-000F23-CV for radiusext-data0@psg.com; Sat, 02 Apr 2011 06:32:54 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5uOB-000F1k-RR for radiusext@ops.ietf.org; Sat, 02 Apr 2011 06:32:52 +0000 Message-ID: <4D96C310.4040200@deployingradius.com> Date: Sat, 02 Apr 2011 08:32:48 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon CC: "'radiusext@ops.ietf.org'" Subject: Re: 6rd attribute compromise? References: <9BC2F7926B33FE4AB10D69891D58FC1C5B555A194E@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Peter Deacon wrote: > As a compromise any thoughts about defining stand-ins for what are > essentially TLVs to remove external dependencies? It's a good idea, I think. > Upside future implementations supporting TLVs *may* be able to more > broadly support the 6rd configuration attribute. > > Downside at least 7 more bytes for this attribute, more work to manage > additional static fields. I'm not concerned about 7 bytes, and TLVs should make it easier to add more fields. The extended attrs document says that TLV formats should not be used for "normal" attributes. That's only because it may be useful to group all of the new features together. That can be changed. An alternative approach would be to publish a "new data types" RFC, containing just TLV and 64-bit integer data types. It should be simple enough that publication should be quick. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 3 05:44:37 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A477B3A67E1 for ; Sun, 3 Apr 2011 05:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvN-6VYkAmKT for ; Sun, 3 Apr 2011 05:44:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 188D53A67DF for ; Sun, 3 Apr 2011 05:44:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q6MdA-000Ocb-Gz for radiusext-data0@psg.com; Sun, 03 Apr 2011 12:42:12 +0000 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q6Md6-000Obf-8O for radiusext@ops.ietf.org; Sun, 03 Apr 2011 12:42:09 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU3GmAcF/2dsb2JhbACmZXSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.63,291,1299474000"; d="scan'208";a="239893156" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Apr 2011 08:41:03 -0400 X-IronPort-AV: E=Sophos;i="4.63,291,1299474000"; d="scan'208";a="604705129" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Apr 2011 08:41:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Call for Nominees - RADEXT WG co-chair Date: Sun, 3 Apr 2011 14:41:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Nominees - RADEXT WG co-chair Thread-Index: Acvx/GN3FIYVbeN7SV+nEJcHE56NoQ== From: "Romascanu, Dan (Dan)" To: "radext mailing list" Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi,=20 As announced in the WG meeting in Prague, following his nomination as Chair of the IAB Bernard Aboba will need to release some of his current positions among which the position of co-chair of the RADEXT WG.=20 Thanks to Bernard for his exceptional contributions as WG chair.=20 I am opening the process of selection of a new co-chair to lead the working group together with Mauricio who is continuing in his position. If you feel qualified and are willing to serve as RADEXT WG co-chair please send me a mail on this respect before Tuesday 4/12.=20 Thanks and Regards, Dan=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Apr 4 00:58:34 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9023A6934 for ; Mon, 4 Apr 2011 00:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDl3E81epdrx for ; Mon, 4 Apr 2011 00:58:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 74D443A6920 for ; Mon, 4 Apr 2011 00:58:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q6eeY-000HLL-Tg for radiusext-data0@psg.com; Mon, 04 Apr 2011 07:56:50 +0000 Received: from smtprelay.restena.lu ([2001:a18:1::62]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q6eeW-000HL0-FK for radiusext@ops.ietf.org; Mon, 04 Apr 2011 07:56:48 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7EAD2107B5; Mon, 4 Apr 2011 09:56:46 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6B2B9106CB; Mon, 4 Apr 2011 09:56:46 +0200 (CEST) Message-ID: <4D9979BB.7040803@restena.lu> Date: Mon, 04 Apr 2011 09:56:43 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ignacio Goyret CC: Mark Smith , Alan DeKok , "radiusext@ops.ietf.org" Subject: Re: 64 bit data types References: <4D9367E4.9040208@restena.lu> <4D936B33.60200@deployingradius.com> <4D95080A.2090004@internode.com.au> <201103312322.p2VNMcIU003328@cliff.eng.ascend.com> In-Reply-To: <201103312322.p2VNMcIU003328@cliff.eng.ascend.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig04A48BB437536CFD7FABA983" X-Virus-Scanned: ClamAV Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig04A48BB437536CFD7FABA983 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> I think there would be a very useful benefit in 64 bit data types. >> .... >> 64 bit counters would mean one less thing to handle in accounting >> code, and one less thing to have to worry about testing. > +1 Good! Alan suggested the extended-attributes draft to handle this. I second that, since a new datatype is a more architectural change, and deserves more visibility, than the simple things "fancyaccounting" tries to achieve. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig04A48BB437536CFD7FABA983 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Zeb4ACgkQ+jm90f8eFWb67wCeMn5JKyGWkRAZhRRcmwdIeJse MD0AnRu4IDPaaz2Z4uovJXwuhJAZvkYf =sZY/ -----END PGP SIGNATURE----- --------------enig04A48BB437536CFD7FABA983-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Apr 8 11:35:23 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A133A6972 for ; Fri, 8 Apr 2011 11:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.948 X-Spam-Level: X-Spam-Status: No, score=-104.948 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRqXxm8hCBrG for ; Fri, 8 Apr 2011 11:35:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 72CDF3A6962 for ; Fri, 8 Apr 2011 11:35:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8GVR-000FsP-2c for radiusext-data0@psg.com; Fri, 08 Apr 2011 18:34:05 +0000 Received: from g5t0008.atlanta.hp.com ([15.192.0.45]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8GVM-000FqU-A5 for radiusext@ops.ietf.org; Fri, 08 Apr 2011 18:34:00 +0000 Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id 0144C245A6 for ; Fri, 8 Apr 2011 18:33:57 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 8 Apr 2011 18:32:49 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Fri, 8 Apr 2011 18:32:49 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Fri, 8 Apr 2011 18:30:56 +0000 Subject: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acv2GxXYOSeCUwMVR9aWHRCiIJ9EjA== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9GVW0671EXCame_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During IETF 80 one of the agenda topics discussed was whether to approve a = request received by IANA for allocation of additional NAS-port-type values = relating to Wimax as described below Type of Assignment : Nas-Port-Type values as follows: TBD for WIMAX-3GPP-PRIF: WiMAX Pre-Release 8 IWK Function TBD for WIMAX-WIFI-IWK: WiMAX WIFI Interworking TBD for WIMAX-SFF: Signaling Forwarding Function for LTE/3GPP2. TBD for WIMAX-HA-LMA: WiMAX HA and or LMA function. TBD for WIMAX-DHCP : WIMAX DCHP service TBD for WIMAX- LBS : WiMAX location based service TBD for WIMAX-WVS : WiMAX voice service The snippet of meeting notes relating to this topic are show below: ---- --------------------------- Request for registration for NAS-port-type. Under 3575, falls under expert= review. This request is for NAS-port-type relating to WiMax - Stefan comments that there's already type for WiFi so not sure why anothe= r one is needed, just one. - Klaas comments that agrees with Stefan's comments. - Nancy comments that looking at the current assignment is that there is on= ly 1 allocation per mode. - Bernard takes the general comment of only allocating one as the response = to take back to the request. Given consensus here, will verify that opinio= n in the reflector. ---- --------------------------- The sentiment in the room was clearly against approving this IANA request a= nd at this time we would like to confirm this on the mailing list. Please respond to this email and state whether you are in favor or against = approving this IANA request. Thanks, MS --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During IETF 80 o= ne of the agenda topics discussed was whether to approve a request received= by IANA for allocation of additional NAS-port-type values relating to Wima= x as described below

 <= /p>

Type of Assignment :
Nas-Port-Type values as fol= lows:
TBD for WIMAX-3GPP-PRIF:  WiMAX Pre-Release 8 IWK Functi= on
TBD for WIMAX-WIFI-IWK:  WiMAX   WIFI Interworking
= TBD for WIMAX-SFF: Signaling Forwarding Function  for LTE/3GPP2.<= br>TBD for WIMAX-HA-LMA:  WiMAX HA and or LMA   functio= n.
TBD for WIMAX-DHCP : WIMAX DCHP service

TBD for WIMAX- LBS  : WiMAX location based service
TBD f= or WIMAX-WVS : WiMAX  voice service

 

The snippet of meeting note= s relating to this topic are show below:

 

---- <meeting note snippet be= gin>---------------------------

=  

Request for registration for NAS-port= -type.  Under 3575, falls under expert review.  This request is f= or NAS-port-type relating to WiMax

- Ste= fan comments that there’s already type for WiFi so not sure why anoth= er one is needed, just one.

- Klaas comm= ents that agrees with Stefan’s comments.

- Nancy comments that looking at the current assignment is that ther= e is only 1 allocation per mode.

- Berna= rd takes the general comment of only allocating one as the response to take= back to the request.  Given consensus here, will verify that opinion = in the reflector.

 

<= p class=3DMsoNormal>---- <meeting note snippet end>------------------= ---------

 

The sentiment in the room was clearly against approving this I= ANA request and at this time we would like to confirm this on the mailing l= ist.  

 

Please respond to this email and state whether you are in fav= or or against approving this IANA request. 

 

Thanks,

<= p class=3DMsoNormal>MS

 

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9GVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Apr 9 13:57:13 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE373A694F for ; Sat, 9 Apr 2011 13:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3kgmnydsbCf for ; Sat, 9 Apr 2011 13:57:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B8C693A68CB for ; Sat, 9 Apr 2011 13:57:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8fCV-0008zf-JS for radiusext-data0@psg.com; Sat, 09 Apr 2011 20:56:11 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8fCR-0008zT-V9 for radiusext@ops.ietf.org; Sat, 09 Apr 2011 20:56:08 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1Q8fCM-000823-W7; Sat, 09 Apr 2011 13:56:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 09 Apr 2011 20:56:02 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #89: Key Wrap and Password Hiding Requirements X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/radext/trac/ticket/89#comment:1 Message-ID: <075.bba5fde9390a211500f0aa6a61ce6096@trac.tools.ietf.org> References: <066.cff106be913743859c8f78dbb4aeb58d@trac.tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <066.cff106be913743859c8f78dbb4aeb58d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #89: Key Wrap and Password Hiding Requirements Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed Resolution: Change the following text in Section 4.2: It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. This includes providing support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption. To: It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption. Solutions providing for encryption of entire RADIUS packets need not also provide support for encryption of individual RADIUS attributes. Solutions providing for encryption of individual RADIUS attributes are REQUIRED to provide support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Apr 9 14:08:56 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202853A696D for ; Sat, 9 Apr 2011 14:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAfkA41rq-5E for ; Sat, 9 Apr 2011 14:08:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF13D3A681B for ; Sat, 9 Apr 2011 14:08:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8fNz-0009qr-SS for radiusext-data0@psg.com; Sat, 09 Apr 2011 21:08:03 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8fNw-0009qg-OZ for radiusext@ops.ietf.org; Sat, 09 Apr 2011 21:08:01 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1Q8fNt-0006p0-LS; Sat, 09 Apr 2011 14:07:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 09 Apr 2011 21:07:57 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #92: End-to-end versus hop-by-hop confidentiality X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/radext/trac/ticket/92 Message-ID: <066.c8181cac1a08fae95845dd7c3e9fa8b7@trac.tools.ietf.org> X-Trac-Ticket-ID: 92 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #92: End-to-end versus hop-by-hop confidentiality The document currently does not make it clear what the requirements are for end-to-end confidentiality. The proposal is to change the text on "Limit Key Scope" in Section 4.2 to the following: Limit key scope It is RECOMMENDED that solutions enable a NAS and RADIUS server to exchange confidential information such as keying material without disclosure to third parties. In order to accomplish this, it is RECOMMENDED that a RADIUS crypto-agility solution be compatible with NAI-based Dynamic Peer Discovery [RADYN] as well as that it support the use of public key credentials for authentication between the NAS and RADIUS server. For compatibility with existing operations, RADIUS crypto-agility solutions SHOULD also support pre-shared key credentials. However, support for end-to-end confidentiality of attributes or direct communications between the NAS and RADIUS server is not required when pre-shared key credentials are used. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 10 11:53:37 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8963A6953 for ; Sun, 10 Apr 2011 11:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErRuUWlTcwuh for ; Sun, 10 Apr 2011 11:53:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A49413A6876 for ; Sun, 10 Apr 2011 11:53:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8zhj-000BcZ-Ld for radiusext-data0@psg.com; Sun, 10 Apr 2011 18:49:47 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8zhg-000BcH-Fq for radiusext@ops.ietf.org; Sun, 10 Apr 2011 18:49:44 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1Q8zhc-0003Uc-6P; Sun, 10 Apr 2011 11:49:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 10 Apr 2011 18:49:40 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #71: Section 2.3 and 3.3 X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/71#comment:4 Message-ID: <075.2072b49294f08276ddbd367ff589ecd9@trac.tools.ietf.org> References: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #71: Section 2.3 and 3.3 Comment(by bernard_aboba@…): We discussed the distinction between the various attributes at IETF-80: Framed-IPv6-Prefix: Configures an IPv6 prefix (and route) for the user on the NAS and results in the prefix being advertised in an RA from the NAS. Framed-IPv6-Route: Configures additional routes on the NAS. These additional routes may be advertised by an IGP, depending on the value of Framed-Routing. Route-IPv6-Information: Configures additional routes on the NAS. These additional routes will be advertised within the RA via the Route Information Option described in RFC 4191 Section 2.3. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 10 11:55:00 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FEE73A6937 for ; Sun, 10 Apr 2011 11:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEjkpdGzK++5 for ; Sun, 10 Apr 2011 11:54:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1ED7F3A6876 for ; Sun, 10 Apr 2011 11:54:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8zla-000Bu9-3y for radiusext-data0@psg.com; Sun, 10 Apr 2011 18:53:46 +0000 Received: from blu0-omc1-s35.blu0.hotmail.com ([65.55.116.46]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q8zlW-000Btw-MF for radiusext@ops.ietf.org; Sun, 10 Apr 2011 18:53:42 +0000 Received: from BLU152-W17 ([65.55.116.8]) by blu0-omc1-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Apr 2011 11:53:41 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_5d4939f6-cab7-48ec-8b52-aab0c8efdadc_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Route-IPv6-Information Attribute Date: Sun, 10 Apr 2011 11:53:41 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Apr 2011 18:53:41.0986 (UTC) FILETIME=[9C5D5C20:01CBF7B0] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_5d4939f6-cab7-48ec-8b52-aab0c8efdadc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF-80 we discussed the differences between the Framed-IPv6-Prefix=2C F= ramed-IPv6-Route and Route-IPv6-Information attributes. The differences ap= pear to be as follows: Framed-IPv6-Prefix: Configures an IPv6 prefix (and route) for the user on = the NAS and results in the prefix being advertised in an RA from the NAS.=20 Framed-IPv6-Route: Configures additional routes on the NAS. These additio= nal routes may be advertised by an IGP=2C depending on the value of Framed-Routing.=20 Route-IPv6-Information: Configures additional routes on the NAS. These ad= ditional routes will be advertised within the RA via the Route Information = Option described in RFC 4191 Section 2.3.=20 In comparing RFC 4191 Section 2.3 with the format of the Route-IPv6-Informa= tion Attribute=2C there appear to be some differences in the information in= cluded. The Route-IPv6-Information Attribute does not include the Route Pr= eference or the Route Lifetime within the Route Information Option. Also t= he definition of the Prefix Length and Prefix appears to be different. Is = there a reason for this?=20 Assuming that it is desirable to utilize the same format for the Attribute = and the Option=2C potential replacement text for Section 3.3 would be as fo= llows: 3.3. Route-IPv6-Information This Attribute specifies a prefix (and corresponding route) for the user on the NAS=2C which is to be announced using the Route Information Option defined in "Default Router Preferences and More Specific Routes" [RFC4191] Section 2.3. It is used in the Access-Accept=20 packet and can appear multiple times. It may also be used in the Access-Request packet as hint to the server. A summary of the Route-IPv6-Information attribute format is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA3 for Route-IPv6-Information Length Length in bytes. At least 4 and no larger than 20=3B typically 12 or less. Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The Prefix field is 0=2C 8=2C or 16 octets depending o= n Length. Prf (Route Preference) 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others=2C when multiple identical prefixes (for different routers) have been received.=20 Resvd (Reserved) Two 3-bit unused fields. They MUST be initialized to zero. Route Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xffffffff) represents infinity. Prefix Variable-length field containing an IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. Does this make sense? = --_5d4939f6-cab7-48ec-8b52-aab0c8efdadc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF-80 we discussed the differences between the Framed-IPv6-Prefix=2C F= ramed-IPv6-Route and Route-IPv6-Information attributes. =3B The differe= nces appear to be as follows:

Framed-IPv6-Prefix: =3B Configures= an IPv6 prefix (and route) for the user on the NAS and results in the pref= ix being advertised in an RA from the NAS.

Framed-IPv6-Route: = =3B Configures additional routes on the NAS. =3B These additional route= s may be advertised by an IGP=2C
depending on the value of Framed-Routin= g.

Route-IPv6-Information: =3B Configures additional routes on = the NAS. =3B These additional routes will be advertised within the RA v= ia the Route Information Option described in RFC 4191 Section 2.3.

= In comparing RFC 4191 Section 2.3 with the format of the Route-IPv6-Informa= tion Attribute=2C there appear to be some differences in the information in= cluded. =3B The Route-IPv6-Information Attribute does not include the R= oute Preference or the Route Lifetime within the Route Information Option.&= nbsp=3B Also the definition of the Prefix Length and Prefix appears to be d= ifferent. =3B Is there a reason for this?

Assuming that it is d= esirable to utilize the same format for the Attribute and the Option=2C pot= ential replacement text for Section 3.3 would be as follows:

3.3. Ro= ute-IPv6-Information

 =3B =3B This Attribute specifies a pre= fix (and corresponding route) for the
 =3B =3B user on the NAS= =2C which is to be announced using the Route Information
 =3B = =3B Option defined in "Default Router Preferences and More Specific
&nbs= p=3B =3B Routes" [RFC4191] Section 2.3. =3B =3B It is used in t= he Access-Accept
 =3B =3B packet and can appear multiple times.=  =3B It may also be
 =3B =3B used in the Access-Request pack= et as hint to the server.

 =3B =3B A summary of the Route-IP= v6-Information attribute format is shown
 =3B =3B below.

=  =3B =3B =3B =3B =3B 0 =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B 1 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B 2 =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B 3
 =3B =3B =3B =3B =3B&= nbsp=3B 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=  =3B =3B =3B =3B =3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =3B =3B =3B =3B =3B= | =3B =3B =3B =3B Type =3B =3B =3B =3B&nbs= p=3B | =3B =3B =3B Length =3B =3B =3B =3B | Pre= fix Length |Resvd|Prf|Resvd|
 =3B =3B =3B =3B =3B +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =3B=  =3B =3B =3B =3B | =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B Route = Lifetime =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B |
 =3B =3B&n= bsp=3B =3B =3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
 =3B =3B =3B =3B =3B | =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B Prefix (Variable Leng= th) =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B |
 =3B =3B =3B =3B =3B . =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B .
 =3B =3B =3B =3B =3B .=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B .
 =3B =3B = =3B =3B =3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+

 =3B =3B Type

 =3B =3B =3B&nbs= p=3B =3B TBA3 for Route-IPv6-Information

 =3B =3B Length=

 =3B =3B =3B =3B =3B Length in bytes. =3B A= t least 4 and no larger than 20=3B typically 12
 =3B =3B =3B=  =3B =3B or less.

 =3B =3B Prefix Length
 =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B 8-bit unsigned integer. =3B The number of= leading bits in
 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B the Prefix that= are valid. =3B The value ranges from 0 to
 =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B 128. =3B The Prefix field is 0=2C 8=2C or 16 octets depend= ing on
 =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B Length.

 =3B&nbs= p=3B Prf (Route Preference)
 =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B 2-bit = signed integer. =3B The Route Preference indicates
 =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B whether to prefer the router associated with this pref= ix
 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B over others=2C when multiple id= entical prefixes (for
 =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B different ro= uters) have been received.

 =3B =3B Resvd (Reserved)
&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B Two 3-bit unused fields. =3B They M= UST be initialized to
 =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B zero.
 =3B =3B Route Lifetime
 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= 32-bit unsigned integer. =3B The length of time in seconds
 =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B (relative to the time the packet is sent) tha= t the prefix
 =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B is valid for route de= termination. =3B A value of all one
 =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B bits (0xffffffff) represents infinity.

 =3B =3B Prefix=  =3B =3B =3B =3B =3B Variable-length field containing a= n IP address or a
 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B prefix of an IP= address. =3B The Prefix Length field
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B contains the number of valid leading bits in the prefix.
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B The bits in the prefix after the prefix le= ngth (if any)
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B are reserved and MUS= T be initialized to zero.


Does this make sense?



= = --_5d4939f6-cab7-48ec-8b52-aab0c8efdadc_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 10 12:21:21 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73CD93A6961 for ; Sun, 10 Apr 2011 12:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+jyqbpOUQBq for ; Sun, 10 Apr 2011 12:21:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 536A53A6876 for ; Sun, 10 Apr 2011 12:21:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q909f-000DYB-41 for radiusext-data0@psg.com; Sun, 10 Apr 2011 19:18:39 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q909b-000DXt-C4 for radiusext@ops.ietf.org; Sun, 10 Apr 2011 19:18:36 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1Q909Y-0001Vj-7a; Sun, 10 Apr 2011 12:18:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 10 Apr 2011 19:18:32 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #69: Section 1 X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/69#comment:4 Message-ID: <075.e85e9a1e9b07c1692899b187d5ca16c3@trac.tools.ietf.org> References: <066.2bae7a4d167a08e0f441859ab7024657@trac.tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <066.2bae7a4d167a08e0f441859ab7024657@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #69: Section 1 Comment(by bernard_aboba@…): Here is some revised text: This document specifies additional RADIUS attributes used to support configuration of DHCPv6 and/or ICMPv6 parameters on a per-user basis. The attributes, which complement those defined in [RFC3162] and [RFC4818], support the following: o Assignment of specific IPv6 addresses to hosts via DHCPv6. While [RFC3162] permits an IPv6 address to be specified via the combination of the Framed-Interface-Id and Framed-IPv6-Prefix attributes, this separation is more natural for use with IPv6CP than it is for use with DHCPv6, and the use of a single IPv6 address attribute makes for easier processing of accounting records. o Assignment of an IPv6 DNS server address, via DHCPv6 or [RFC5006]. o Configuration of more specific routes to be announced to the user via the Route Information Option defined in [RFC4191] Section 2.3. While the Framed-IPv6-Prefix Attribute defined in [RFC3162] Section 2.3 causes the route to be advertised in an RA, it cannot be used to configure more specific routes. While the Framed-IPv6-Route Attribute defined in [RFC3162] Section 2.5 causes the route to be configured on the NAS, and potentially announced via an IGP, depending on the value of Framed-Routing, it does not result in the route being announced in an RA. o The assignment of a named delegated prefix pool for use with "IPv6 Prefix Options for DHCPv6" [RFC3633]. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 10 12:25:13 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38633A68EC for ; Sun, 10 Apr 2011 12:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLg1wBUDYRMG for ; Sun, 10 Apr 2011 12:25:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ABC023A6876 for ; Sun, 10 Apr 2011 12:25:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q90Cn-000Djw-O4 for radiusext-data0@psg.com; Sun, 10 Apr 2011 19:21:53 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q90Cj-000Djm-VQ for radiusext@ops.ietf.org; Sun, 10 Apr 2011 19:21:50 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1Q90Cg-0000db-UU; Sun, 10 Apr 2011 12:21:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 10 Apr 2011 19:21:46 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #71: Section 2.3 and 3.3 X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/71#comment:5 Message-ID: <075.3754ce10466b7b5d17205d842dc5e86b@trac.tools.ietf.org> References: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #71: Section 2.3 and 3.3 Comment(by bernard_aboba@…): Here is potential replacement text for Section 3.3: 3.3. Route-IPv6-Information This Attribute specifies a prefix (and corresponding route) for the user on the NAS, which is to be announced using the Route Information Option defined in "Default Router Preferences and More Specific Routes" [RFC4191] Section 2.3. It is used in the Access-Accept packet and can appear multiple times. It may also be used in the Access-Request packet as hint to the server. A summary of the Route-IPv6-Information attribute format is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA3 for Route-IPv6-Information Length Length in bytes. At least 4 and no larger than 20; typically 12 or less. Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The Prefix field is 0, 8, or 16 octets depending on Length. Prf (Route Preference) 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others, when multiple identical prefixes (for different routers) have been received. Resvd (Reserved) Two 3-bit unused fields. They MUST be initialized to zero. Route Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xffffffff) represents infinity. Prefix Variable-length field containing an IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 10 13:43:50 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B473A698B for ; Sun, 10 Apr 2011 13:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bzmpTKcYX1L for ; Sun, 10 Apr 2011 13:43:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 911A53A6989 for ; Sun, 10 Apr 2011 13:43:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q91Ro-000IEl-Rs for radiusext-data0@psg.com; Sun, 10 Apr 2011 20:41:28 +0000 Received: from mout.perfora.net ([74.208.4.194]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q91Rh-000IET-Ki for radiusext@ops.ietf.org; Sun, 10 Apr 2011 20:41:21 +0000 Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MLf11-1Q8kSg1pHX-0013rD; Sun, 10 Apr 2011 16:41:17 -0400 From: "Alper Yegin" To: "'Sanchez, Mauricio \(HP Networking\)'" , References: <9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9@GVW0671EXC.americas.hpqcorp.net> In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9@GVW0671EXC.americas.hpqcorp.net> Subject: RE: Consensus poll for IANA #409959 NAS-Port-Type value request Date: Sun, 10 Apr 2011 23:41:12 +0300 Message-ID: <03b801cbf7bf$a4d24910$ee76db30$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03B9_01CBF7D8.CA1F8110" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv2GxXYOSeCUwMVR9aWHRCiIJ9EjABo7Mig Content-Language: en-us X-Provags-ID: V02:K0:HneTM6Z7Zw2NUWzKEkfy5vD9uKu87TEn/03Kt9WQ1qm KRUIJX1DheWqAePDiaLKL1gGPrnCfXXooCIKPfbwmiwpKfhiJp pwCxECFgy+FYHXehvB71xSGH56dID1tM05FCBM50cC+2qpOPMR /ZngXDE/VQrL6BgsYBfUkoxwPj4L2bBMq+uOvLuMaDiH9KIBv2 XJqQCIcOWlrj9sZ7x1SYvnjIi1D9KdUVFlZogdnRDI= Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multipart message in MIME format. ------=_NextPart_000_03B9_01CBF7D8.CA1F8110 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03BA_01CBF7D8.CA1F8110" ------=_NextPart_001_03BA_01CBF7D8.CA1F8110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Avi had sent an email explaining how this is not same as regular WiFi access. Please see the attachment for his email. Neither Avi nor I was at the meeting to re-iterate these points. Hopefully this explanation is sufficient. If not, let us know. Alper From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (HP Networking) Sent: Friday, April 08, 2011 9:31 PM To: 'radiusext@ops.ietf.org' Subject: Consensus poll for IANA #409959 NAS-Port-Type value request During IETF 80 one of the agenda topics discussed was whether to approve a request received by IANA for allocation of additional NAS-port-type values relating to Wimax as described below Type of Assignment : Nas-Port-Type values as follows: TBD for WIMAX-3GPP-PRIF: WiMAX Pre-Release 8 IWK Function TBD for WIMAX-WIFI-IWK: WiMAX WIFI Interworking TBD for WIMAX-SFF: Signaling Forwarding Function for LTE/3GPP2. TBD for WIMAX-HA-LMA: WiMAX HA and or LMA function. TBD for WIMAX-DHCP : WIMAX DCHP service TBD for WIMAX- LBS : WiMAX location based service TBD for WIMAX-WVS : WiMAX voice service The snippet of meeting notes relating to this topic are show below: ---- --------------------------- Request for registration for NAS-port-type. Under 3575, falls under expert review. This request is for NAS-port-type relating to WiMax - Stefan comments that there's already type for WiFi so not sure why another one is needed, just one. - Klaas comments that agrees with Stefan's comments. - Nancy comments that looking at the current assignment is that there is only 1 allocation per mode. - Bernard takes the general comment of only allocating one as the response to take back to the request. Given consensus here, will verify that opinion in the reflector. ---- --------------------------- The sentiment in the room was clearly against approving this IANA request and at this time we would like to confirm this on the mailing list. Please respond to this email and state whether you are in favor or against approving this IANA request. Thanks, MS ------=_NextPart_001_03BA_01CBF7D8.CA1F8110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Avi had sent an email = explaining how this is not same as regular WiFi access. Please see the attachment = for his email.

 

Neither Avi nor I was = at the meeting to re-iterate these points. Hopefully this explanation is = sufficient. If not, let us know.

 

Alper

 

 

 

From:= = owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, = Mauricio (HP Networking)
Sent: Friday, April 08, 2011 9:31 PM
To: 'radiusext@ops.ietf.org'
Subject: Consensus poll for IANA #409959 NAS-Port-Type value = request

 

During IETF 80 one of the agenda topics discussed = was whether to approve a request received by IANA for allocation of = additional NAS-port-type values relating to Wimax as described below =

 

Type of Assignment :
Nas-Port-Type values as follows:
TBD for WIMAX-3GPP-PRIF:  WiMAX Pre-Release 8 IWK Function
TBD for WIMAX-WIFI-IWK:  WiMAX   WIFI Interworking
TBD for WIMAX-SFF: Signaling Forwarding Function  for = LTE/3GPP2.
TBD for WIMAX-HA-LMA:  WiMAX HA and or = LMA   function.
TBD for WIMAX-DHCP : WIMAX DCHP service

TBD for WIMAX- LBS  : WiMAX location = based service
TBD for WIMAX-WVS : WiMAX  voice service

 

The snippet of meeting notes relating to this topic = are show below:

 

---- <meeting note snippet begin>---------------------------

 

Request for registration for NAS-port-type.  = Under 3575, falls under expert review.  This request is for NAS-port-type relating to WiMax

- Stefan comments that there’s already type = for WiFi so not sure why another one is needed, just one.

- Klaas comments that agrees with Stefan’s = comments.

- Nancy comments that looking at the current = assignment is that there is only 1 allocation per mode.

- Bernard takes the general comment of only = allocating one as the response to take back to the request.  Given consensus here, = will verify that opinion in the reflector.

 

---- <meeting note snippet end>---------------------------

 

The sentiment in the room was clearly against = approving this IANA request and at this time we would like to confirm this on the = mailing list.  

 

Please respond to this email and state whether you = are in favor or against approving this IANA request. 

 

Thanks,

MS

 

------=_NextPart_001_03BA_01CBF7D8.CA1F8110-- ------=_NextPart_000_03B9_01CBF7D8.CA1F8110 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by mx.perfora.net (node=mxus0) with ESMTP (Nemesis) id 0MRnhx-1PWinr3eK9-00T7qC for alper.yegin@yegin.org; Tue, 15 Mar 2011 13:39:39 -0400 Received: (qmail 27728 invoked from network); 15 Mar 2011 17:39:37 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-5.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2011 17:39:37 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 15 Mar 2011 13:39:36 -0400 Return-Path: From: "Avi Lior" To: Cc: , "Alper Yegin" Subject: [IANA #409959] Genreral Request for Assignements Date: Tue, 15 Mar 2011 20:39:35 +0300 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B4_01CBF7D8.CA078C40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjN/PfETWqJsnhRbCJ3Q5584NJVA== Content-Language: en-us X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Originating-IP: [72.35.6.119] X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-5.tower-200.messagelabs.com!1300210776!92153259!1 X-StarScan-Version: 6.2.9; banners=-,-,- This is a multipart message in MIME format. ------=_NextPart_000_03B4_01CBF7D8.CA078C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bernard, Thank you for the review of the NAS-Port-Type IANA request for assignment. In a previous email you were seeking answers to the following questions: Bernard wrote: Can someone answer the following questions? 1. What is different between WiMAX WiFi and normal IEEE 802.11? We already have a number of IEEE 802.11 NAS-Port-types allocated and have proposed additional data for this. 2. Why do DHCP and a location service need NAS-Port-Type values? 3. Why should we just allocate a generic WiMAX NAS-Port and let additional data be included in a WiMAX Forum VSA? The general answer to your question is as follows: For a given session, the WIMAX AAA Server interacts with many different WiMAX network elements and also non-WiMAX network elements. The approach taken by WiMAX is to have an explicit indication from the NAS as to the context of the RADIUS access-request. The NAS-Port-Type is viewed as the attribute to provide that information. WRT 1) the WiMAX AAA needs to be able to differentiate between a normal WiFi Access and a WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additional behaviours over and above the "normal" wifi AP. T WRT 2) Again, WiMAX AAA needs to differentiate between the request from both these entities because the AAA behaviour is different when request comes from a DHCP server vs., a Location Based Server. WRT 3) WiMAX would just be inventing our own NAS-Port-Type attribute. We thought the idea is that we reuse attributes when we can. Since there doesn't seem to be a lack of number space associated with NAS-Port-Type there doesn't seem to be a reason to invent our own attribute. -- Avi Lior --Bridgewater Systems ------=_NextPart_000_03B4_01CBF7D8.CA078C40 Content-Type: text/html; boundary="_000_C9A51C9711D20avibridgewatersystemscom_"; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 Hi = Bernard,

Thank you for the review of the = NAS-Port-Type IANA request for assignment.  In a previous email you = were seeking answers to the following questions:

Bernard wrote:

Can someone = answer the following questions?

1. What is = different between WiMAX WiFi and normal IEEE 802.11?  We already = have a number of IEEE 802.11 NAS-Port-types allocated and have proposed = additional data for this.

2. Why do DHCP and a location service = need NAS-Port-Type values? 

3. Why = should we just allocate a generic WiMAX NAS-Port and let additional data = be included in a WiMAX Forum VSA?

The general answer to your question = is as follows:

For a given session, the WIMAX AAA Server interacts with many = different WiMAX network elements and also non-WiMAX network elements. =  The approach taken by WiMAX is to have an explicit indication from = the NAS as to the context of the RADIUS access-request.  The = NAS-Port-Type is viewed as the attribute to provide that = information.

WRT 1) the WiMAX AAA needs to be able to = differentiate between a normal WiFi Access and a WiMAX NAS which is an a = WiFI-WiMAX IWK NAS which has additional behaviours over and above the = "normal" wifi AP.  T


WRT 2) Again, WiMAX AAA needs to = differentiate between the request from both these entities because the = AAA behaviour is different when request comes from  a DHCP server = vs., a Location Based Server.

WRT 3)  WiMAX would just be inventing = our own NAS-Port-Type attribute.  We thought the idea is that we = reuse attributes when we can. Since there doesn't seem to be a lack of = number space associated with NAS-Port-Type there doesn't seem to be a = reason to invent our own attribute.


-- Avi = Lior
--Bridgewater = Systems

------=_NextPart_000_03B4_01CBF7D8.CA078C40-- ------=_NextPart_000_03B9_01CBF7D8.CA1F8110-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 10 22:55:53 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F0B3A6A84 for ; Sun, 10 Apr 2011 22:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTNexab0fbB6 for ; Sun, 10 Apr 2011 22:55:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FE5A3A6A82 for ; Sun, 10 Apr 2011 22:55:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9A1q-000II4-Rz for radiusext-data0@psg.com; Mon, 11 Apr 2011 05:51:14 +0000 Received: from smtprelay.restena.lu ([2001:a18:1::62]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9A1o-000IHo-9H for radiusext@ops.ietf.org; Mon, 11 Apr 2011 05:51:12 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 0AF8C106CB; Mon, 11 Apr 2011 07:51:10 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id F30D010694; Mon, 11 Apr 2011 07:51:09 +0200 (CEST) Message-ID: <4DA296C9.20301@restena.lu> Date: Mon, 11 Apr 2011 07:51:05 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alper Yegin CC: "'Sanchez, Mauricio \(HP Networking\)'" , radiusext@ops.ietf.org Subject: Re: Consensus poll for IANA #409959 NAS-Port-Type value request References: <9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9@GVW0671EXC.americas.hpqcorp.net> <03b801cbf7bf$a4d24910$ee76db30$@yegin@yegin.org> In-Reply-To: <03b801cbf7bf$a4d24910$ee76db30$@yegin@yegin.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8C3133073BC9630676D8BC63" X-Virus-Scanned: ClamAV Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8C3133073BC9630676D8BC63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =20 > > Avi had sent an email explaining how this is not same as regular WiFi > access. Please see the attachment for his email. > > =20 > > Neither Avi nor I was at the meeting to re-iterate these points. > Hopefully this explanation is sufficient. If not, let us know. > > I for one didn't get the difference between normal WiFi and WiMAX-Wifi-IWK. The email sounded like WiMAX is doing WiFi+additional things, i.e. a "profile" of WiFi. The argument in the meeting was: is the stuff that WiMAX-Wifi is doing conformant to IEEE 802.11? If yes, it *is* WiFi and there's a NAS-Port-Type allocation for it already. If it is *not* conforming to IEEE 802.11, then maybe it needs a new NAS-Port-Type. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig8C3133073BC9630676D8BC63 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ils0ACgkQ+jm90f8eFWYUfACcCwF1LcWIHyalS2DPODWPpgqN boEAoIJnqxkLGOBFvM4A2hxLqu2O45GW =NHmL -----END PGP SIGNATURE----- --------------enig8C3133073BC9630676D8BC63-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Apr 11 03:33:15 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB55728C0F0 for ; Mon, 11 Apr 2011 03:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDZYRF4MV0G2 for ; Mon, 11 Apr 2011 03:33:14 -0700 (PDT) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 91CB928C0F4 for ; Mon, 11 Apr 2011 03:33:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9EJ5-0004Ph-0k for radiusext-data0@psg.com; Mon, 11 Apr 2011 10:25:19 +0000 Received: from mail200.messagelabs.com ([216.82.254.195]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9EJ1-0004PO-2x for radiusext@ops.ietf.org; Mon, 11 Apr 2011 10:25:15 +0000 X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-4.tower-200.messagelabs.com!1302517512!77711697!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 13636 invoked from network); 11 Apr 2011 10:25:13 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-4.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 11 Apr 2011 10:25:13 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Mon, 11 Apr 2011 06:25:11 -0400 From: Avi Lior To: "Sanchez, Mauricio (HP Networking)" , "'radiusext@ops.ietf.org'" Date: Mon, 11 Apr 2011 06:24:37 -0400 Subject: Re: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acv4Mrx3Bi71uZxORzeaMPGsCKrocw== Message-ID: In-Reply-To: <9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: multipart/alternative; boundary="_000_C9C89DCA1344Aavibridgewatersystemscom_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_C9C89DCA1344Aavibridgewatersystemscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Regarding the below comments: - Stefan comments that there=92s already type for WiFi so not sure why anot= her one is needed, just one. - Klaas comments that agrees with Stefan=92s comments. - Nancy comments that looking at the current assignment is that there is on= ly 1 allocation per mode. Maybe it wasn't made clear why WiMAX requires these assignment. An email wa= s sent recently and also this was discussed previously on the RADEXT reflec= tor (See Nov. 2009). Briefly: The AAA in WiMAX is responsible to interact with various types of WiMAX NAS= es and also non-WiMAX NASes: The AAA thus needs to be able to determine wh= ich type of NAS it communicates with to determine the context of the Access= -Request. WiMAX decided that it want an explicit indication of the type of= NAS and hence wants to use the NAS-Port-Type to determine the context of t= he call. The question is whether or not the NAS-Port-Type is the attribute to be use= d for that. The answer seems to be yes. Second, the objection also seems to be based the number being requested. I= s there a shortage of numbers? I don't think so. This was also discussed = by the group in the past. -- Avi Lior --Bridgewater Systems On 08-04-11 14:30 , "Sanchez, Mauricio (HP Networking)" > wrote: During IETF 80 one of the agenda topics discussed was whether to approve a = request received by IANA for allocation of additional NAS-port-type values = relating to Wimax as described below Type of Assignment : Nas-Port-Type values as follows: TBD for WIMAX-3GPP-PRIF: WiMAX Pre-Release 8 IWK Function TBD for WIMAX-WIFI-IWK: WiMAX WIFI Interworking TBD for WIMAX-SFF: Signaling Forwarding Function for LTE/3GPP2. TBD for WIMAX-HA-LMA: WiMAX HA and or LMA function. TBD for WIMAX-DHCP : WIMAX DCHP service TBD for WIMAX- LBS : WiMAX location based service TBD for WIMAX-WVS : WiMAX voice service The snippet of meeting notes relating to this topic are show below: ---- --------------------------- Request for registration for NAS-port-type. Under 3575, falls under expert= review. This request is for NAS-port-type relating to WiMax - Stefan comments that there=92s already type for WiFi so not sure why anot= her one is needed, just one. - Klaas comments that agrees with Stefan=92s comments. - Nancy comments that looking at the current assignment is that there is on= ly 1 allocation per mode. - Bernard takes the general comment of only allocating one as the response = to take back to the request. Given consensus here, will verify that opinio= n in the reflector. ---- --------------------------- The sentiment in the room was clearly against approving this IANA request a= nd at this time we would like to confirm this on the mailing list. Please respond to this email and state whether you are in favor or against = approving this IANA request. Thanks, MS --_000_C9C89DCA1344Aavibridgewatersystemscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Regarding the below comments:

- Stefan comments th= at there=92s already type for WiFi so not sure why another one is needed, j= ust one.

- Klaas comments that agrees with Stef= an=92s comments.

- Nancy comments that looking = at the current assignment is that there is only 1 allocation per mode.=


Maybe it wasn't made clear wh= y WiMAX requires these assignment. An email was sent recently and also this= was discussed previously on the RADEXT reflector (See Nov. 2009).


Briefly:


The AAA in WiMAX is responsible to interact with various types of WiM= AX NASes and also non-WiMAX NASes:  The AAA thus needs to be able to d= etermine which type of NAS it communicates with to determine the context of= the Access-Request.  WiMAX decided that it want an explicit indicatio= n of the type of NAS and hence wants to use the NAS-Port-Type to determine = the context of the call.   



=

Second, the objection also seems to be based the number b= eing requested.  Is there a shortage of numbers?  I don't think s= o.  This was also discussed by the group in the past.




-- Avi L= ior
--Bridgewater Systems

<= /div>

On 08-04-11= 14:30 , "Sanchez, Mauricio (HP Networking)" <mauricio.sanchez@hp.com> wrote:

During IETF = 80 one of the agenda topics discussed was whether to approve a request rece= ived by IANA for allocation of additional NAS-port-type values relating to = Wimax as described below

 <= /o:p>

Type of Assignment :
Nas-Port-Type value= s as follows:
TBD for WIMAX-3GPP-PRIF:  WiMAX Pre-Release 8 IW= K Function
TBD for WIMAX-WIFI-IWK:  WiMAX   WIFI Interwor= king
TBD for WIMAX-SFF: Signaling Forwarding Function  for LTE= /3GPP2.
TBD for WIMAX-HA-LMA:  WiMAX HA and or LMA   = ;function.
TBD for WIMAX-DHCP : WIMAX DCHP service

TBD for WIMAX- LBS  : WiMAX location based servic= e
TBD for WIMAX-WVS : WiMAX  voice service

 

The snippet o= f meeting notes relating to this topic are show below:

 

---- <meeti= ng note snippet begin>---------------------------

 

Request for reg= istration for NAS-port-type.  Under 3575, falls under expert review.&n= bsp; This request is for NAS-port-type relating to WiMax

- Stefan comments that there=92s already type for WiFi s= o not sure why another one is needed, just one.

- Klaas comments that agrees with Stefan=92s comments.=

- Nancy comments that looking at the current ass= ignment is that there is only 1 allocation per mode.

- Bernard takes the general comment of only allocating one a= s the response to take back to the request.  Given consensus here, wil= l verify that opinion in the reflector.

 

---- <meeting note snippet= end>---------------------------

 

The sentiment in the room was cle= arly against approving this IANA request and at this time we would like to = confirm this on the mailing list.  

 

Please respond to this email= and state whether you are in favor or against approving this IANA request.=  

 

Thanks,

MS <= /p>

 

--_000_C9C89DCA1344Aavibridgewatersystemscom_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Apr 11 20:30:45 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 19B77E06F3 for ; Mon, 11 Apr 2011 20:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sh1enWHVIlbj for ; Mon, 11 Apr 2011 20:30:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 1F1CFE06F2 for ; Mon, 11 Apr 2011 20:30:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9UFd-000830-G3 for radiusext-data0@psg.com; Tue, 12 Apr 2011 03:26:49 +0000 Received: from szxga01-in.huawei.com ([119.145.14.64]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9UFY-000826-Fe for radiusext@ops.ietf.org; Tue, 12 Apr 2011 03:26:45 +0000 Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJI000QCS6KFZ@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Tue, 12 Apr 2011 11:25:32 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJI00FR0S6J2Z@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Tue, 12 Apr 2011 11:25:32 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 12 Apr 2011 11:25:18 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.4.122]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Tue, 12 Apr 2011 11:25:30 +0800 Date: Tue, 12 Apr 2011 03:25:30 +0000 From: Jiangsheng Subject: Re: 6rd attribute compromise? X-Originating-IP: [10.110.98.101] To: Alan DeKok Cc: Peter Deacon , radiusext Message-id: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Re: 6rd attribute compromise? Thread-index: Acv4wUM7dE/ZV6sVSvu0/NYIa3QUdg== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: EDy5 JS0e LIgl Mode NvLt Ri/T SAA2 U69v WXW3 Wk4z XGy9 X4M2 blM4 fQT8 f469 iRr0;3;YQBsAGEAbgBkAEAAZABlAHAAbABvAHkAaQBuAGcAcgBhAGQAaQB1AHMALgBjAG8AbQA7AHAAZQB0AGUAcgBkAEAAaQBlAGEALQBzAG8AZgB0AHcAYQByAGUALgBjAG8AbQA7AHIAYQBkAGkAdQBzAGUAeAB0AEAAbwBwAHMALgBpAGUAdABmAC4AbwByAGcA;Sosha1_v1;7;{11BE8C4E-0E76-4A44-A29E-F1AE02F57574};agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A;Tue, 12 Apr 2011 03:25:25 GMT;UgBlADoAIAA2AHIAZAAgAGEAdAB0AHIAaQBiAHUAdABlACAAYwBvAG0AcAByAG8AbQBpAHMAZQA/AA== x-cr-puzzleid: {11BE8C4E-0E76-4A44-A29E-F1AE02F57574} Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi, Alan and Peter, Sorry for the late reply. The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969. However, if this is not compatible with RADIUS, we would like to accept any suggestion from RADEXT WG. So, the first question is whether our current 6rd attr design is NOT acceptable by RADIUS. If the answer is NO, Peter's suggestion looks good for us except why a Reserved byte. The second choice could be we limit 6rdBRIPv4Address to be only 1 instance. Then we have a fixed length attribute. But this need to enable grouping multiple attributes module, which seems RADIUS protocol does not support currently. We do not understand Alan's third approach. Could Alan explain a little bit more, "An alternative approach would be to publish a "new data types" RFC, containing just TLV and 64-bit integer data types." And how this relevant to our 6rd attribute? Best regards, Sheng & Dayong -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Apr 11 22:47:35 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C41F9E072B for ; Mon, 11 Apr 2011 22:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqnL2imlEXFZ for ; Mon, 11 Apr 2011 22:47:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id C0026E067E for ; Mon, 11 Apr 2011 22:47:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9WO7-000Dft-DS for radiusext-data0@psg.com; Tue, 12 Apr 2011 05:43:43 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9WO4-000Dfc-Hu for radiusext@ops.ietf.org; Tue, 12 Apr 2011 05:43:40 +0000 Message-ID: <4DA3E688.5040401@deployingradius.com> Date: Tue, 12 Apr 2011 07:43:36 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jiangsheng CC: Peter Deacon , radiusext Subject: Re: 6rd attribute compromise? References: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Jiangsheng wrote: > The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969. Please see RFC 6158, Section 3.2.4. If you are transporting a pre-defined data type in RADIUS, then don't re-define it in RADIUS. Instead, just say "this attribute has the format as described in RFC 5969 Section 7.1.1" > However, if this is not compatible with RADIUS, we would like to accept any suggestion from RADEXT WG. So, the first question is whether our current 6rd attr design is NOT acceptable by RADIUS. It does not follow the guidelines set down in RFC 6158. > If the answer is NO, Peter's suggestion looks good for us except why a Reserved byte. I think using TLVs for this attribute would be a good choice, but not necessarily better than referring to a pre-existing data format. > We do not understand Alan's third approach. Could Alan explain a little bit more, "An alternative approach would be to publish a "new data types" RFC, > containing just TLV and 64-bit integer data types." And how this relevant to our 6rd attribute? You could use the new data types in the document, rather than inventing a data type which is incompatible with existing RADIUS practice. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Apr 11 23:50:59 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 98226E074A for ; Mon, 11 Apr 2011 23:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjyJrNl26BNQ for ; Mon, 11 Apr 2011 23:50:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 902E3E070A for ; Mon, 11 Apr 2011 23:50:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9XNt-000G9i-IY for radiusext-data0@psg.com; Tue, 12 Apr 2011 06:47:33 +0000 Received: from szxga01-in.huawei.com ([119.145.14.64]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9XNk-000G9F-GW for radiusext@ops.ietf.org; Tue, 12 Apr 2011 06:47:26 +0000 Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJJ009YJ1IX5M@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Tue, 12 Apr 2011 14:47:21 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJJ00DWA1IUJQ@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Tue, 12 Apr 2011 14:47:21 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 12 Apr 2011 14:47:16 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.4.122]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 12 Apr 2011 14:47:17 +0800 Date: Tue, 12 Apr 2011 06:47:17 +0000 From: Jiangsheng Subject: RE: 6rd attribute compromise? In-reply-to: <4DA3E688.5040401@deployingradius.com> X-Originating-IP: [10.110.98.101] To: Alan DeKok Cc: Peter Deacon , radiusext Message-id: <5D36713D8A4E7348A7E10DF7437A4B9282C299@SZXEML504-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: 6rd attribute compromise? Thread-index: AQHL+NVNg0EtjQPRfU2ZBV7YAqmC45RZwdwg X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: FuMr Gity GuCS HYCX Lzim L1FB NrLh Pl4G X4QH X/8B bYCP cWe2 e5SR g86M iKJh jICw;3;YQBsAGEAbgBkAEAAZABlAHAAbABvAHkAaQBuAGcAcgBhAGQAaQB1AHMALgBjAG8AbQA7AHAAZQB0AGUAcgBkAEAAaQBlAGEALQBzAG8AZgB0AHcAYQByAGUALgBjAG8AbQA7AHIAYQBkAGkAdQBzAGUAeAB0AEAAbwBwAHMALgBpAGUAdABmAC4AbwByAGcA;Sosha1_v1;7;{3B4D01C9-D7AC-4D12-BB7F-45458CDA7B9C};agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A;Tue, 12 Apr 2011 06:47:11 GMT;UgBFADoAIAA2AHIAZAAgAGEAdAB0AHIAaQBiAHUAdABlACAAYwBvAG0AcAByAG8AbQBpAHMAZQA/AA== x-cr-puzzleid: {3B4D01C9-D7AC-4D12-BB7F-45458CDA7B9C} References: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com> <4DA3E688.5040401@deployingradius.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi, Alan, Thanks for your reply. It is much clearer now. After carefully read RFC 6158, we don't think the attribute can be referred to a pre-existing data format because this attribute should be parsed by the Radius server. In 6rd scenarios, it is the Radius server who manages the user configuration information. Therefore, this 6rd attribute can NOT "be treated as opaque data by the RADIUS server." So, it leaves TLVs the best choice. As the below, I slightly modified Peter's proposal by removing the Reserved byte. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SubType (1) | SubLen (3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4MaskLen | SubType (2) | SubLen (19) | 6rdPrefixLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 6rdPrefix | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubType (3) | SubLen (6) | 6rdBRIPv4Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6rdBRIPv4Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Any further comments? Peter, do you have any particular reasons to add the Reserved byte back? Sheng > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Alan DeKok > Sent: Tuesday, April 12, 2011 1:44 PM > To: Jiangsheng > Cc: Peter Deacon; radiusext > Subject: Re: 6rd attribute compromise? > > Jiangsheng wrote: > > The format design of this 6rd attribute was to be the same with 6rd > DHCPv4 Option, please see section 7.1.1 of RFC 5969. > > Please see RFC 6158, Section 3.2.4. If you are transporting a > pre-defined data type in RADIUS, then don't re-define it in RADIUS. > Instead, just say "this attribute has the format as described in RFC > 5969 Section 7.1.1" > > > However, if this is not compatible with RADIUS, we would like to > accept any suggestion from RADEXT WG. So, the first question is whether > our current 6rd attr design is NOT acceptable by RADIUS. > > It does not follow the guidelines set down in RFC 6158. > > > If the answer is NO, Peter's suggestion looks good for us except why > a Reserved byte. > > I think using TLVs for this attribute would be a good choice, but not > necessarily better than referring to a pre-existing data format. > > > We do not understand Alan's third approach. Could Alan explain a > little bit more, "An alternative approach would be to publish a "new > data types" RFC, > > containing just TLV and 64-bit integer data types." And how this > relevant to our 6rd attribute? > > You could use the new data types in the document, rather than > inventing a data type which is incompatible with existing RADIUS > practice. > > Alan DeKok. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Apr 11 23:53:33 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 55C62E070A for ; Mon, 11 Apr 2011 23:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqXBPKRyMo0L for ; Mon, 11 Apr 2011 23:53:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 49828E0749 for ; Mon, 11 Apr 2011 23:53:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9XRh-000GKe-20 for radiusext-data0@psg.com; Tue, 12 Apr 2011 06:51:29 +0000 Received: from remote.iea-software.com ([70.89.142.196] helo=aspen.internal.iea-software.com) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9XRc-000GKU-Qw for radiusext@ops.ietf.org; Tue, 12 Apr 2011 06:51:24 +0000 Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 11 Apr 2011 23:51:24 -0700 Date: Mon, 11 Apr 2011 23:50:33 -0700 (Pacific Daylight Time) From: Peter Deacon To: Jiangsheng cc: Alan DeKok , radiusext Subject: Re: 6rd attribute compromise? In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com> Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: On Tue, 12 Apr 2011, Jiangsheng wrote: > The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969. > > However, if this is not compatible with RADIUS, we would like to accept > any suggestion from RADEXT WG. So, the first question is whether our > current 6rd attr design is NOT acceptable by RADIUS. > If the answer is NO, Peter's suggestion looks good for us except why a > Reserved byte. Hi Jiangsheng, just included reserved /w ascii example to be a closer match to the existing attribute format for prefix (RFC 3162 2.3) regards, Peter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Apr 12 00:03:49 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D325EE0750 for ; Tue, 12 Apr 2011 00:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnD-43hFHjHg for ; Tue, 12 Apr 2011 00:03:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 347A3E0724 for ; Tue, 12 Apr 2011 00:03:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9XaP-000Ghe-CN for radiusext-data0@psg.com; Tue, 12 Apr 2011 07:00:29 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9XaH-000GhG-53 for radiusext@ops.ietf.org; Tue, 12 Apr 2011 07:00:21 +0000 Message-ID: <4DA3F881.8030607@deployingradius.com> Date: Tue, 12 Apr 2011 09:00:17 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon CC: Jiangsheng , radiusext Subject: Re: 6rd attribute compromise? References: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Peter Deacon wrote: > Hi Jiangsheng, just included reserved /w ascii example to be a closer > match to the existing attribute format for prefix (RFC 3162 2.3) I agree with Peter here. Leaving the reserved byte in place allows many RADIUS servers to use these new attributes with only a dictionary update. Deleting the reserved byte means that the IPv6 prefix for 6rd has a different format than for all other IPv6 prefix attributes. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Apr 12 00:26:03 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 03575E0786 for ; Tue, 12 Apr 2011 00:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M-smBaSjMpk for ; Tue, 12 Apr 2011 00:26:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 2E4B9E0785 for ; Tue, 12 Apr 2011 00:26:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9Xup-000HjA-SC for radiusext-data0@psg.com; Tue, 12 Apr 2011 07:21:35 +0000 Received: from szxga04-in.huawei.com ([119.145.14.67]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9Xul-000Hiw-DD for radiusext@ops.ietf.org; Tue, 12 Apr 2011 07:21:32 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJJ00A7J324TT@szxga04-in.huawei.com> for radiusext@ops.ietf.org; Tue, 12 Apr 2011 15:20:28 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LJJ00MWX31QHJ@szxga04-in.huawei.com> for radiusext@ops.ietf.org; Tue, 12 Apr 2011 15:20:28 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 12 Apr 2011 15:19:58 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.4.122]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Tue, 12 Apr 2011 15:19:26 +0800 Date: Tue, 12 Apr 2011 07:19:26 +0000 From: Jiangsheng Subject: RE: 6rd attribute compromise? In-reply-to: <4DA3F881.8030607@deployingradius.com> X-Originating-IP: [10.110.98.101] To: Alan DeKok , Peter Deacon Cc: radiusext Message-id: <5D36713D8A4E7348A7E10DF7437A4B9282C2D3@SZXEML504-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: 6rd attribute compromise? Thread-index: AQHL+N7y9/vyP9NEykaaS1J8YmjSDpRZRrSAgACKlMA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com> <4DA3F881.8030607@deployingradius.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: OK, I will put the reserved byte back. I will wait another two or three days in case there are other comments, then update a new version with the new TLVs. After that, softwire chair will probably launch the WGLC on both softwire and radext wg mail list. :) Many thanks, Sheng > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Alan DeKok > Sent: Tuesday, April 12, 2011 3:00 PM > To: Peter Deacon > Cc: Jiangsheng; radiusext > Subject: Re: 6rd attribute compromise? > > Peter Deacon wrote: > > Hi Jiangsheng, just included reserved /w ascii example to be a closer > > match to the existing attribute format for prefix (RFC 3162 2.3) > > I agree with Peter here. Leaving the reserved byte in place allows > many RADIUS servers to use these new attributes with only a dictionary > update. > > Deleting the reserved byte means that the IPv6 prefix for 6rd has a > different format than for all other IPv6 prefix attributes. > > Alan DeKok. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Apr 13 03:47:08 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4581DE0710 for ; Wed, 13 Apr 2011 03:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPU32MI3Sdb1 for ; Wed, 13 Apr 2011 03:47:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 5387DE06C1 for ; Wed, 13 Apr 2011 03:47:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9xXg-000CQt-3z for radiusext-data0@psg.com; Wed, 13 Apr 2011 10:43:24 +0000 Received: from mail51.messagelabs.com ([216.82.241.99]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9xXZ-000CQh-RT for radiusext@ops.ietf.org; Wed, 13 Apr 2011 10:43:18 +0000 X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-8.tower-51.messagelabs.com!1302691395!58334024!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 22889 invoked from network); 13 Apr 2011 10:43:15 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-8.tower-51.messagelabs.com with RC4-SHA encrypted SMTP; 13 Apr 2011 10:43:15 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Wed, 13 Apr 2011 06:43:14 -0400 From: Avi Lior To: Dave Nelson CC: "Sanchez, Mauricio (HP Networking)" , "radiusext@ops.ietf.org" Date: Wed, 13 Apr 2011 06:43:12 -0400 Subject: Re: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acv5x5d9c2F6BJ6YREKfKqbqFBjm2g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi Dave, Thanks for your comments. On 11-04-11 14:46 , "Dave Nelson" wrote: >On Mon, Apr 11, 2011 at 6:24 AM, Avi Lior >wrote: > >> WiMAX decided that it want an explicit indication of the type of NAS >>and hence wants to use the NAS-Port-Type to determine the context of the >>call. > >In other words, using NAS-Port-Type to mean NAS-Type. If the >properties of the port itself are the same, this seems confusing. >Maybe what's needed is a NAS-Type attribute? I still think its a NAS-Port-Type. A given NAS may have different NAS-Port-Types or more to the point, offer more then one type of connection/service. The finest granularity is the "Port" or the connection or the service the is being authenticated/authorized. In any case, the NAS-Port-Type is good enough. I don't think we need to invent another thing. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Apr 13 05:24:38 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08875E06B6 for ; Wed, 13 Apr 2011 05:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSU2heks-gDa for ; Wed, 13 Apr 2011 05:24:37 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 24A0CE0693 for ; Wed, 13 Apr 2011 05:24:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9z38-000Gpk-B7 for radiusext-data0@psg.com; Wed, 13 Apr 2011 12:19:59 +0000 Received: from mail37.messagelabs.com ([216.82.241.83]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q9z31-000GpR-4b for radiusext@ops.ietf.org; Wed, 13 Apr 2011 12:19:51 +0000 X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-12.tower-37.messagelabs.com!1302697188!62034349!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 20616 invoked from network); 13 Apr 2011 12:19:48 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-12.tower-37.messagelabs.com with RC4-SHA encrypted SMTP; 13 Apr 2011 12:19:48 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Wed, 13 Apr 2011 08:19:48 -0400 From: Avi Lior To: Dave Nelson CC: "Sanchez, Mauricio (HP Networking)" , "radiusext@ops.ietf.org" Date: Wed, 13 Apr 2011 08:19:32 -0400 Subject: Re: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acv51RQYZ7+waTcFQt6WuN3OZAao8g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: See inline... -- Avi Lior --Bridgewater Systems On 13-04-11 13:27 , "Dave Nelson" wrote: >On Wed, Apr 13, 2011 at 6:43 AM, Avi Lior >wrote: > >> The finest granularity is the "Port" or the connection or the service >>the >> is being authenticated/authorized. > >Yes. Do you envision a situation where a single NAS would report an a >802.11 port type on one connection ans a WiMAX-802.11 port type on >another connection? Actually yes. Imagine if you will a web server that is authenticating users for WiFi and one that is authenticating user for something else. My point is that if I only worry about the "ports" instead of the NAS, I couldn't possibly fall into a "trap" later on. The trap being the assumption that a NAS is homogeneous. The question then becomes what benefit(s) do I get for treating the NAS as a homogeneous set of ports. > Or would the NAS only report various combinations >of WiMAX specific connections? > >> In any case, the NAS-Port-Type is good enough. > >Yeah, a lot of things we do with RADIUS are "good enough", even if >they are not completely correct, in terms of a coherent >object-oriented data model. I'm not endorsing that behavior, just >taking note of it. > >Regards, > >Dave > >David B. Nelson >Sr. Software Architect >Elbrys Networks, Inc. >www.elbrys.com >+1.603.570.2636 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Apr 16 19:29:51 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B9245E0661 for ; Sat, 16 Apr 2011 19:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w8+jHnwiLRZ for ; Sat, 16 Apr 2011 19:29:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id DD811E0660 for ; Sat, 16 Apr 2011 19:29:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBHiX-000EHM-Ck for radiusext-data0@psg.com; Sun, 17 Apr 2011 02:28:05 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBHiS-000EH8-5E for radiusext@ops.ietf.org; Sun, 17 Apr 2011 02:28:00 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QBHiQ-0002fh-BT; Sat, 16 Apr 2011 19:27:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 17 Apr 2011 02:27:58 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #90: Process for publication and selection X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/90#comment:1 Message-ID: <075.0132e29ebbe223e3f7b71c25d86ee288@trac.tools.ietf.org> References: <066.e58b887196f2be1f6847935efa1523d1@trac.tools.ietf.org> X-Trac-Ticket-ID: 90 In-Reply-To: <066.e58b887196f2be1f6847935efa1523d1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #90: Process for publication and selection Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is to add a Section 1.4 as follows: 1.4. Publication Process RADIUS [RFC2865] is a widely deployed protocol that has attained Draft Standard status based on multiple independent interoperable implementations. It is therefore highly desirable that a high level of interoperability and security be maintained for crypto-agility solutions. To ensure that crypto-agility solutions published on the standards track are well specified, secure and interoperable, the RADEXT WG has adopted a two phase process for publication of crypto-agility solutions. In the initial phase, crypto-agility solutions adopted by the working group will be published on the Experimental Track. Experimental Track documents should contain a description of experimental deployments and implementations in progress, as well as an evaluation of the proposal against the requirements described in this document. Based on the proposal evaluations, implementation and deployment experience, and the results of interoperability tests, initial proposals will be evaluated for publication on the standards track. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Apr 16 19:30:06 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3ED58E0679 for ; Sat, 16 Apr 2011 19:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzXOHvsFIT3h for ; Sat, 16 Apr 2011 19:30:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 8BC0EE0660 for ; Sat, 16 Apr 2011 19:30:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBHgX-000EED-5n for radiusext-data0@psg.com; Sun, 17 Apr 2011 02:26:01 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBHgR-000EDw-9t for radiusext@ops.ietf.org; Sun, 17 Apr 2011 02:25:55 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QBHgL-0007Ye-5q; Sat, 16 Apr 2011 19:25:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 17 Apr 2011 02:25:49 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #92: End-to-end versus hop-by-hop confidentiality X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/92#comment:1 Message-ID: <075.878c7b191c9a26e9c0cd13413cba225b@trac.tools.ietf.org> References: <066.c8181cac1a08fae95845dd7c3e9fa8b7@trac.tools.ietf.org> X-Trac-Ticket-ID: 92 In-Reply-To: <066.c8181cac1a08fae95845dd7c3e9fa8b7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #92: End-to-end versus hop-by-hop confidentiality Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 17 06:02:46 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 77308E072C for ; Sun, 17 Apr 2011 06:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.574 X-Spam-Level: X-Spam-Status: No, score=-101.574 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5NCKJ2CE3HS for ; Sun, 17 Apr 2011 06:02:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 2C2B4E0694 for ; Sun, 17 Apr 2011 06:02:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBRaA-0004nO-TX for radiusext-data0@psg.com; Sun, 17 Apr 2011 13:00:06 +0000 Received: from mail.ietf.org ([2001:470:8:3d::1]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBRa8-0004mt-BD for radiusext@ops.ietf.org; Sun, 17 Apr 2011 13:00:04 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2FD2AE0751 for ; Sun, 17 Apr 2011 06:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwLGrMr-OfL0; Sun, 17 Apr 2011 06:00:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A464AE072C; Sun, 17 Apr 2011 06:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110417130001.5280.63645.idtracker@ietfc.amsl.com> Date: Sun, 17 Apr 2011 06:00:01 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Author(s) : D. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-05.txt Pages : 11 Date : 2011-04-16 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-crypto-agility-requirements-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-17054858.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 17 12:05:42 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BAB72E071D for ; Sun, 17 Apr 2011 12:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Qduu4ZAF1Z for ; Sun, 17 Apr 2011 12:05:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 3160CE06A0 for ; Sun, 17 Apr 2011 12:05:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBXDT-000H4u-01 for radiusext-data0@psg.com; Sun, 17 Apr 2011 19:01:03 +0000 Received: from blu0-omc1-s23.blu0.hotmail.com ([65.55.116.34]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBXDP-000H4l-Nr for radiusext@ops.ietf.org; Sun, 17 Apr 2011 19:00:59 +0000 Received: from BLU152-W47 ([65.55.116.8]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Apr 2011 12:00:58 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_5899b8ec-59e8-445e-95f1-061d17174ca0_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: WG Last Call on "Crypto-Agility Requirements for RADIUS" Date: Sun, 17 Apr 2011 12:00:58 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 17 Apr 2011 19:00:58.0442 (UTC) FILETIME=[C96782A0:01CBFD31] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_5899b8ec-59e8-445e-95f1-061d17174ca0_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on "Crypto-Agility Requireme= nts for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-crypto-agility-requirements This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_5899b8ec-59e8-445e-95f1-061d17174ca0_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEXT WG = last call on "Crypto-Agili= ty Requirements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =3B

The document is available for inspection here:

= http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issu= es=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue in = TRAC=2C you first need to login to the RADEXT WG site on the tools server:&= nbsp=3B http://tools.ietf.org/wg/radext/trac/login

2. =3B = =3B =3B =3B =3B =3B If you don=92t already have a login ID= =2C you can obtain one by navigating to this site: =3B =3B http://trac.tool= s.ietf.org/newlogin

3. =3B =3B =3B =3B =3B&n= bsp=3B Once you have obtained an account=2C and have logged in=2C you can f= ile an issue by navigating to the =3B ticket entry form: http://t= rac.tools.ietf.org/wg/radext/trac/newticket

4. =3B =3B&n= bsp=3B =3B =3B =3B When opening an issue:

a. =3B&nbs= p=3B =3B =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tool= s.ietf.org/wg/radext/trac/report/1 =3B Click on the ticket # you wa= nt to update=2C and then modify the ticket fields as required

 =3B

= = --_5899b8ec-59e8-445e-95f1-061d17174ca0_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 17 12:27:46 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C8214E0782 for ; Sun, 17 Apr 2011 12:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTXp0-3QFn-A for ; Sun, 17 Apr 2011 12:27:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 17B94E0780 for ; Sun, 17 Apr 2011 12:27:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBXat-000I4x-5d for radiusext-data0@psg.com; Sun, 17 Apr 2011 19:25:15 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBXaq-000I4k-09 for radiusext@ops.ietf.org; Sun, 17 Apr 2011 19:25:12 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QBXak-0004vt-7n; Sun, 17 Apr 2011 12:25:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: stefan.winter@restena.lu, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 17 Apr 2011 19:25:06 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #3: Review of RTLS document (part 1, Technical) X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/3#comment:2 Message-ID: <075.818a0c8b1c31772a342e7a4561487ffe@trac.tools.ietf.org> References: <066.2d399c2db02b2377eb32a2e4ed0b6a18@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <066.2d399c2db02b2377eb32a2e4ed0b6a18@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: stefan.winter@restena.lu, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #3: Review of RTLS document (part 1, Technical) Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Apr 17 12:38:46 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0F4E3E071C for ; Sun, 17 Apr 2011 12:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJTxSZQwYUvh for ; Sun, 17 Apr 2011 12:38:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id AE0A2E0713 for ; Sun, 17 Apr 2011 12:38:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBXm0-000IUA-OU for radiusext-data0@psg.com; Sun, 17 Apr 2011 19:36:44 +0000 Received: from blu0-omc1-s8.blu0.hotmail.com ([65.55.116.19]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QBXlw-000IU0-V0 for radiusext@ops.ietf.org; Sun, 17 Apr 2011 19:36:41 +0000 Received: from BLU152-W31 ([65.55.116.7]) by blu0-omc1-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Apr 2011 12:36:36 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ee60a55a-079c-4f84-8c1c-8d978797240e_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: WG Last Call on "TLS encryption for RADIUS" Date: Sun, 17 Apr 2011 12:36:36 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 17 Apr 2011 19:36:36.0406 (UTC) FILETIME=[C3BAED60:01CBFD36] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_ee60a55a-079c-4f84-8c1c-8d978797240e_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on "TLS encryption for RADIU= S"=2C prior to sending the document to the IESG for publication as an Experiment= al RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-radsec This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_ee60a55a-079c-4f84-8c1c-8d978797240e_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This = is an announcement of RADEXT WG last call on "TLS encryption for RADIUS"=2C prior to sending the document to the IESG for publication as an Experiment= al RFC. =3B


The document is available for inspection here= :<= /p>

http://tools.ietf= .org/html/draft-ietf-radext-radsec


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issues=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue = in TRAC=2C you first need to login to the RADEXT WG site on the tools serve= r: =3B http://tools.ietf.org/wg/radext/trac/login
2. =3B =3B =3B =3B =3B =3B If you don=92t alr= eady have a login ID=2C you can obtain one by navigating to this site: = =3B =3B http://trac.tools.ietf.org/newlogin

3. = =3B =3B =3B =3B =3B =3B Once you have obtained an accou= nt=2C and have logged in=2C you can file an issue by navigating to the = =3B ticket entry form: http://trac.tools.ietf.org/w= g/radext/trac/newticket

4. =3B =3B =3B =3B = =3B =3B When opening an issue:

a. =3B =3B =3B = =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1 =3B Click on t= he ticket # you want to update=2C and then modify the ticket fields as requ= ired

 =3B

= --_ee60a55a-079c-4f84-8c1c-8d978797240e_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Apr 20 15:28:01 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF0DEE0721 for ; Wed, 20 Apr 2011 15:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEmSmBocR+Wi for ; Wed, 20 Apr 2011 15:28:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id 73644E06B5 for ; Wed, 20 Apr 2011 15:28:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QCfpW-000B3n-W1 for radiusext-data0@psg.com; Wed, 20 Apr 2011 22:25:03 +0000 Received: from blu0-omc1-s33.blu0.hotmail.com ([65.55.116.44]) by psg.com with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QCfpU-000B38-EK for radiusext@ops.ietf.org; Wed, 20 Apr 2011 22:25:00 +0000 Received: from BLU152-W54 ([65.55.116.8]) by blu0-omc1-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 15:24:59 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_43da1465-a057-4a42-9144-1fb483464990_" X-Originating-IP: [72.11.66.126] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Re: WG Last Call on "Crypto-Agility Requirements for RADIUS" Date: Wed, 20 Apr 2011 15:24:59 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2011 22:24:59.0836 (UTC) FILETIME=[C9153FC0:01CBFFA9] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_43da1465-a057-4a42-9144-1fb483464990_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking as an individual=2C I have read this draft and feel it is suitabl= e for publication. I have no specific comments to make at this time.=20 = --_43da1465-a057-4a42-9144-1fb483464990_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking as an individual=2C I =3B have re= ad this draft and feel it is suitable for publication. =3B =3B I ha= ve no specific comments to make at this time.


= --_43da1465-a057-4a42-9144-1fb483464990_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Apr 26 23:21:30 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24ED8E06AF for ; Tue, 26 Apr 2011 23:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS1hL0zWfJw8 for ; Tue, 26 Apr 2011 23:21:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA1FE06AD for ; Tue, 26 Apr 2011 23:21:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QEy4n-000PW0-A3 for radiusext-data0@psg.com; Wed, 27 Apr 2011 06:18:17 +0000 Received: from mail-wy0-f180.google.com ([74.125.82.180]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QEy4h-000PVQ-5h for radiusext@ops.ietf.org; Wed, 27 Apr 2011 06:18:11 +0000 Received: by wyj26 with SMTP id 26so1498011wyj.11 for ; Tue, 26 Apr 2011 23:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=PdvtIWEjOeskUKAv3Njvo8Xr5BonH1rUzQ7651kxzvQ=; b=ngcy/X7Wq8SER5h2YNkb0yh9M0PiI2pwCBOSI1wFHiq9Ch+Gq2PO3wcoap01y+Fgij RTCgtinqN2l6E9nMHksGQrVr3puj0Dc/Zh91/S1/Z+z9Cc1FL3f1N8iEEe66EKG1QDAa a+CTkrrQ1JRIpnX4+cnevxpwC2tV7ZMgPzh40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=C/Ku8rsJkZsOGYJB4SAx41Qbj36aIUOw8C++h1Rg/OWfoIUF/aVnGSDEcYnn+agxyI 67MG0S4dYxTNj15ofXC6xxkvdPb/CfpMwTQeYnPAOC9MxJr3tMsMP+kptWD+OOurb9Qj Yv+45OpnhJTB2reP8VV5VBzXi1oDGVnAJeiic= MIME-Version: 1.0 Received: by 10.216.141.72 with SMTP id f50mr1684579wej.26.1303885089137; Tue, 26 Apr 2011 23:18:09 -0700 (PDT) Received: by 10.216.12.17 with HTTP; Tue, 26 Apr 2011 23:18:09 -0700 (PDT) Date: Wed, 27 Apr 2011 14:18:09 +0800 Message-ID: Subject: Some comments on draft-winter-radext-fancyaccounting-00 From: Jacni Qin To: Stefan Winter Cc: radiusext@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e68e8d2890e32c04a1e0679e Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --0016e68e8d2890e32c04a1e0679e Content-Type: text/plain; charset=ISO-8859-1 Dear Stefan & all, I skimed the draft and got some comments, see below please. * "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to be redundant, I perfer to only keep the Name attribute which is STRING formatted and defined by BNG (configurable). The traffic classes are specified based on the capability of the BNG. No further IANA activities are needed in the future. * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall we "re-use" the type specified in RFC2866, like 245.1.47, etc. * An attribute similar to Type#44 Acct-Session-Id is necessary, since this is widely implemented in practice, for example, as an identification of user for policy changes initiated by AAA server. Name it "Acct-Traffic-Class-Id"? But the value should be a random number assigned by BNG. Some other attributes may also need to be considered. Or, I can propose some text if you want. Cheers, Jacni --0016e68e8d2890e32c04a1e0679e Content-Type: text/html; charset=ISO-8859-1 Dear Stefan & all,

I skimed the draft and got some comments, see below please.

* "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to be redundant, I perfer to only keep the Name attribute which is STRING formatted and defined by BNG (configurable). The traffic classes are specified based on the capability of the BNG. No further IANA activities are needed in the future.

* For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall we "re-use" the type specified in RFC2866, like 245.1.47, etc.

* An attribute similar to Type#44 Acct-Session-Id is necessary, since this is widely implemented in practice, for example, as an identification of user for policy changes initiated by AAA server. Name it "Acct-Traffic-Class-Id"? But the value should be a random number assigned by BNG. Some other attributes may also need to be considered.

Or, I can propose some text if you want.


Cheers,
Jacni


 --0016e68e8d2890e32c04a1e0679e-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Apr 27 00:04:07 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423B3E06C7 for ; Wed, 27 Apr 2011 00:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy2RQ1WD+TC6 for ; Wed, 27 Apr 2011 00:04:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C4A73E06C6 for ; Wed, 27 Apr 2011 00:04:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QEykL-00016W-KX for radiusext-data0@psg.com; Wed, 27 Apr 2011 07:01:13 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QEykF-000166-GJ for radiusext@ops.ietf.org; Wed, 27 Apr 2011 07:01:07 +0000 Message-ID: <4DB7BF30.6070002@deployingradius.com> Date: Wed, 27 Apr 2011 09:01:04 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jacni Qin CC: Stefan Winter , radiusext@ops.ietf.org Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00 References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Jacni Qin wrote: > * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall > we "re-use" the type specified in RFC2866, like 245.1.47, etc. I would strongly recommend not doing that. Re-using the type would lead people to conclude that the type space for TLVs is the same as the type space for "normal" RADIUS attributes. This is not the case. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Apr 27 02:42:49 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034D7E071F for ; Wed, 27 Apr 2011 02:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D03Nx0rXnaFx for ; Wed, 27 Apr 2011 02:42:48 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 44441E06D2 for ; Wed, 27 Apr 2011 02:42:48 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QF1DY-00069G-1W for radiusext-data0@psg.com; Wed, 27 Apr 2011 09:39:32 +0000 Received: from smtprelay.restena.lu ([2001:a18:1::62]) by psg.com with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QF1DR-000692-PY for radiusext@ops.ietf.org; Wed, 27 Apr 2011 09:39:25 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2AAB410694; Wed, 27 Apr 2011 11:39:23 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id B06E010691; Wed, 27 Apr 2011 11:39:22 +0200 (CEST) Message-ID: <4DB7E450.4050400@restena.lu> Date: Wed, 27 Apr 2011 11:39:28 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alan DeKok CC: Jacni Qin , radiusext@ops.ietf.org Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00 References: <4DB7BF30.6070002@deployingradius.com> In-Reply-To: <4DB7BF30.6070002@deployingradius.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0274F0312503D2C55C686DB4" X-Virus-Scanned: ClamAV Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0274F0312503D2C55C686DB4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall= >> we "re-use" the type specified in RFC2866, like 245.1.47, etc. > I would strongly recommend not doing that. Re-using the type would > lead people to conclude that the type space for TLVs is the same as the= > type space for "normal" RADIUS attributes. This is not the case. Also, the data types used here are actually *different* (64 bit integer). Giving them the same number as an already existing attribute with a mismatching data types invites sloppiness errors in implementation= s. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig0274F0312503D2C55C686DB4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk235FAACgkQ+jm90f8eFWaXEwCfSRZTQyX5u42L5/WjeGUJYm9r 924An3LpbxZoTAletcOvAf6UBx6+E6jS =9bbJ -----END PGP SIGNATURE----- --------------enig0274F0312503D2C55C686DB4-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Apr 27 02:54:45 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3A9E06A3 for ; Wed, 27 Apr 2011 02:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnzZKUj1zpk3 for ; Wed, 27 Apr 2011 02:54:45 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 11BB2E0698 for ; Wed, 27 Apr 2011 02:54:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QF1QL-0006W9-L9 for radiusext-data0@psg.com; Wed, 27 Apr 2011 09:52:45 +0000 Received: from smtprelay.restena.lu ([2001:a18:1::62]) by psg.com with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QF1QE-0006Vy-VO for radiusext@ops.ietf.org; Wed, 27 Apr 2011 09:52:39 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 321F010694; Wed, 27 Apr 2011 11:52:38 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 12B2810691; Wed, 27 Apr 2011 11:52:38 +0200 (CEST) Message-ID: <4DB7E768.8070302@restena.lu> Date: Wed, 27 Apr 2011 11:52:40 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jacni Qin CC: radiusext@ops.ietf.org Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00 References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig77C67CB06BF2D8390988954F" X-Virus-Scanned: ClamAV Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig77C67CB06BF2D8390988954F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I skimed the draft and got some comments, see below please. > > * "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to be > redundant, I perfer to only keep the Name attribute which is STRING > formatted and defined by BNG (configurable). The traffic classes are > specified based on the capability of the BNG. No further IANA > activities are needed in the future. It's true that any value expressed in -Id could also be formulated in a string in -Name. However, naming conventions for the string are likely to differ, so I would prefer to have controlled vocabulary at least for more common use cases - like DSCP classes or IP versions, as in the draft= =2E Another option would be to follow Alan's comment regarding NAS-Filter-Rule naming. I'm not much of fan of this, because the first examples which came to my mind: IP versions, DSCP values, don't sit together in IPFilterRule (which is the basis for NAS-Filter-Rule). Only IP versions could be expressed as a filter with NAS-Filter-Rule, but DSCP is a Diameter QoSFilterRule - which can't be expressed in NAS-Filter-Rule (I'll be happy to be corrected if I'm wrong here). > * An attribute similar to Type#44 Acct-Session-Id is necessary, since > this is widely implemented in practice, for example, as an > identification of user for policy changes initiated by AAA server. > Name it "Acct-Traffic-Class-Id"? But the value should be a random > number assigned by BNG. Some other attributes may also need to be > considered. The example in the draft only shows a fragment of the entire Accounting packet. The Accounting packet will be able to contain the Acct-Session-Id, and then additionally one or more groups of Accounting-Traffic-Group. I don't see an issue with that unless one would want to have different session Id's for different traffic groups in the same accounting ticket - but I have a hard time thinking of a reason for that; after all all the counted Octets and Packets belong to the same user session, and can thus share the same session id. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig77C67CB06BF2D8390988954F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2352sACgkQ+jm90f8eFWbUCgCfUNBOk/HzVGPfbpqnws1syOW1 lhYAnibhTsblIhE1yNIQDBPAXuRlkPNb =ppBx -----END PGP SIGNATURE----- --------------enig77C67CB06BF2D8390988954F-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Apr 27 10:38:44 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05737E07DA for ; Wed, 27 Apr 2011 10:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE4cOts2amsy for ; Wed, 27 Apr 2011 10:38:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id F3B0EE07C7 for ; Wed, 27 Apr 2011 10:38:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QF8dK-0003ST-8h for radiusext-data0@psg.com; Wed, 27 Apr 2011 17:34:38 +0000 Received: from remote.iea-software.com ([70.89.142.196] helo=aspen.internal.iea-software.com) by psg.com with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QF8dE-0003S7-Ce for radiusext@ops.ietf.org; Wed, 27 Apr 2011 17:34:32 +0000 Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id for ; Wed, 27 Apr 2011 10:34:30 -0700 Date: Wed, 27 Apr 2011 10:34:30 -0700 (Pacific Daylight Time) From: Peter Deacon To: radiusext@ops.ietf.org Subject: Byte counting in draft-winter-radext-fancyaccounting-00 In-Reply-To: <4DB7E768.8070302@restena.lu> Message-ID: References: <4DB7E768.8070302@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: There is sometimes confusion (For me anyway) regarding what counters actually count. Traditionally Input/Output octets are protocol agnostic and just count low layer bits shuffled between interfaces. Lets say we run IPv6 over PPP or Ethernet do the byte counts apply only to the higher layer IP frames and not a lower layer ethernet or PPP frame? Alternately if there was a traffic class for even higher layer messages such as HTTP..does it count the HTTP layer only or the IP header and possibly ethernet/PPP header? I don't really have an opinion on the behavior only that it would be best if all implementations stand a good chance of counting the same way. regards, Peter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Apr 28 03:33:00 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0D0E06F5 for ; Thu, 28 Apr 2011 03:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+ohqsvZYiKL for ; Thu, 28 Apr 2011 03:32:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2037CE06AC for ; Thu, 28 Apr 2011 03:32:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFOUM-000EFk-7J for radiusext-data0@psg.com; Thu, 28 Apr 2011 10:30:26 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFOUG-000EFC-69 for radiusext@ops.ietf.org; Thu, 28 Apr 2011 10:30:20 +0000 Message-ID: <4DB941B6.5010509@deployingradius.com> Date: Thu, 28 Apr 2011 12:30:14 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon CC: radiusext@ops.ietf.org Subject: Re: Byte counting in draft-winter-radext-fancyaccounting-00 References: <4DB7E768.8070302@restena.lu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Peter Deacon wrote: > There is sometimes confusion (For me anyway) regarding what counters > actually count. Traditionally Input/Output octets are protocol agnostic > and just count low layer bits shuffled between interfaces. > > Lets say we run IPv6 over PPP or Ethernet do the byte counts apply only > to the higher layer IP frames and not a lower layer ethernet or PPP frame? I'd say it's still bits over the interface, including ethernet or PPP. > Alternately if there was a traffic class for even higher layer messages > such as HTTP..does it count the HTTP layer only or the IP header and > possibly ethernet/PPP header? We can define traffic classes for all of that, I think. > I don't really have an opinion on the behavior only that it would be > best if all implementations stand a good chance of counting the same way. The specification needs to be clear on what is being counted. It would help to have specific examples of this in the doc. e.g. If the description is "HTTP traffic on port 80", then the data being counted should be *only* HTTP, not lower-layer TCP, IP, etc. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Apr 29 09:46:51 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34281E06D3 for ; Fri, 29 Apr 2011 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.773 X-Spam-Level: X-Spam-Status: No, score=-102.773 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXxt8DH-GOtB for ; Fri, 29 Apr 2011 09:46:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 28412E06AD for ; Fri, 29 Apr 2011 09:46:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFqm6-000NFp-Ij for radiusext-data0@psg.com; Fri, 29 Apr 2011 16:42:38 +0000 Received: from blu0-omc1-s18.blu0.hotmail.com ([65.55.116.29]) by psg.com with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFqlz-000NED-U9 for radiusext@ops.ietf.org; Fri, 29 Apr 2011 16:42:32 +0000 Received: from BLU152-W31 ([65.55.116.9]) by blu0-omc1-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Apr 2011 09:42:30 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1c19f56d-0343-447e-857a-8bfeec71138d_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: REMINDER: RADEXT WG Last Call on "TLS encryption for RADIUS" Date: Fri, 29 Apr 2011 09:42:30 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2011 16:42:30.0919 (UTC) FILETIME=[6EB11970:01CC068C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_1c19f56d-0343-447e-857a-8bfeec71138d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a reminder of an ongoing RADEXT WG last call on "TLS encryption fo= r RADIUS"=2C prior to sending the document to the IESG for publication as an Experiment= al RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-radsec This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_1c19f56d-0343-447e-857a-8bfeec71138d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This = is a reminder of an ongoing =3B RADEXT WG last call on "TLS encryption fo= r RADIUS"=2C prior to sending the document to the IESG for publication as an Experiment= al RFC. =3B


The document is available for inspection here= :<= /p>

http://tools.ietf= .org/html/draft-ietf-radext-radsec


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issues=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue = in TRAC=2C you first need to login to the RADEXT WG site on the tools serve= r: =3B http://tools.ietf.org/wg/radext/trac/login
2. =3B =3B =3B =3B =3B =3B If you don=92t alr= eady have a login ID=2C you can obtain one by navigating to this site: = =3B =3B http://trac.tools.ietf.org/newlogin

3. = =3B =3B =3B =3B =3B =3B Once you have obtained an accou= nt=2C and have logged in=2C you can file an issue by navigating to the = =3B ticket entry form: http://trac.tools.ietf.org/w= g/radext/trac/newticket

4. =3B =3B =3B =3B = =3B =3B When opening an issue:

a. =3B =3B =3B = =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1 =3B Click on t= he ticket # you want to update=2C and then modify the ticket fields as requ= ired

 =3B

= --_1c19f56d-0343-447e-857a-8bfeec71138d_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Apr 29 09:47:02 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF051E06EA for ; Fri, 29 Apr 2011 09:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.738 X-Spam-Level: X-Spam-Status: No, score=-102.738 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5YKazhzvPcH for ; Fri, 29 Apr 2011 09:46:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 49926E06E8 for ; Fri, 29 Apr 2011 09:46:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFqnD-000NKb-By for radiusext-data0@psg.com; Fri, 29 Apr 2011 16:43:47 +0000 Received: from blu0-omc1-s19.blu0.hotmail.com ([65.55.116.30]) by psg.com with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFqn6-000NJx-Og for radiusext@ops.ietf.org; Fri, 29 Apr 2011 16:43:40 +0000 Received: from BLU152-W31 ([65.55.116.8]) by blu0-omc1-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Apr 2011 09:43:40 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d96f528a-16a4-46d4-b2c6-e683fb7d9087_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS" Date: Fri, 29 Apr 2011 09:43:39 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2011 16:43:40.0180 (UTC) FILETIME=[97F97D40:01CC068C] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_d96f528a-16a4-46d4-b2c6-e683fb7d9087_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a reminder of an ongoing RADEXT WG last call on "Crypto-Agility Req= uirements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-crypto-agility-requirements This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_d96f528a-16a4-46d4-b2c6-e683fb7d9087_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

This is a reminder of an ongoing RADE= XT WG last call on "Crypto-A= gility Requirements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =3B

The document is available for inspection here:

= http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issu= es=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue in = TRAC=2C you first need to login to the RADEXT WG site on the tools server:&= nbsp=3B http://tools.ietf.org/wg/radext/trac/login

2. =3B = =3B =3B =3B =3B =3B If you don=92t already have a login ID= =2C you can obtain one by navigating to this site: =3B =3B http://trac.tool= s.ietf.org/newlogin

3. =3B =3B =3B =3B =3B&n= bsp=3B Once you have obtained an account=2C and have logged in=2C you can f= ile an issue by navigating to the =3B ticket entry form: http://t= rac.tools.ietf.org/wg/radext/trac/newticket

4. =3B =3B&n= bsp=3B =3B =3B =3B When opening an issue:

a. =3B&nbs= p=3B =3B =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tool= s.ietf.org/wg/radext/trac/report/1 =3B Click on the ticket # you wa= nt to update=2C and then modify the ticket fields as required

 =3B

= = --_d96f528a-16a4-46d4-b2c6-e683fb7d9087_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Apr 29 09:50:37 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE75E06AD for ; Fri, 29 Apr 2011 09:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhlJ2EO5QaCX for ; Fri, 29 Apr 2011 09:50:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 34D18E0685 for ; Fri, 29 Apr 2011 09:50:32 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFqsF-000NdB-0f for radiusext-data0@psg.com; Fri, 29 Apr 2011 16:48:59 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFqs8-000Ncd-UG for radiusext@ops.ietf.org; Fri, 29 Apr 2011 16:48:53 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFqs7-00078C-3E; Fri, 29 Apr 2011 09:48:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 29 Apr 2011 16:48:51 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #93: Compliance with Crypto-Agility Requirements X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/93 Message-ID: <066.cbbe14ddeb8841047bdcf9c9dd8d3d7b@trac.tools.ietf.org> X-Trac-Ticket-ID: 93 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #93: Compliance with Crypto-Agility Requirements The Crypto-Agility Requirements document now in WG last call (see http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements ) includes the following in Section 1.4: In the initial phase, crypto-agility solutions adopted by the working group will be published on the Experimental Track. Experimental Track documents should contain a description of experimental deployments and implementations in progress, as well as an evaluation of the proposal against the requirements described in this document. The RADSEC document currently does not include this information. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Apr 29 09:51:07 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8F1E06AD for ; Fri, 29 Apr 2011 09:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xjp0TyIfK9tm for ; Fri, 29 Apr 2011 09:51:02 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id DE529E0685 for ; Fri, 29 Apr 2011 09:51:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFqsu-000Ngo-Go for radiusext-data0@psg.com; Fri, 29 Apr 2011 16:49:40 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFqso-000NgF-CM for radiusext@ops.ietf.org; Fri, 29 Apr 2011 16:49:34 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QFqsm-0008DB-L9; Fri, 29 Apr 2011 09:49:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 29 Apr 2011 16:49:32 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #94: Compliance with Crypto-Agility Requirements X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/94 Message-ID: <066.ae2e3be1fcc1e6f3414e9b5a3033cc0c@trac.tools.ietf.org> X-Trac-Ticket-ID: 94 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #94: Compliance with Crypto-Agility Requirements The Crypto-Agility Requirements document now in WG last call (see http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements ) includes the following in Section 1.4: In the initial phase, crypto-agility solutions adopted by the working group will be published on the Experimental Track. Experimental Track documents should contain a description of experimental deployments and implementations in progress, as well as an evaluation of the proposal against the requirements described in this document. The RDTLS document currently does not include this information. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Apr 29 09:53:23 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C716E06BD for ; Fri, 29 Apr 2011 09:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.715 X-Spam-Level: X-Spam-Status: No, score=-102.715 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGir1oTbUoWJ for ; Fri, 29 Apr 2011 09:53:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CCBEBE0685 for ; Fri, 29 Apr 2011 09:53:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFquJ-000Np6-KN for radiusext-data0@psg.com; Fri, 29 Apr 2011 16:51:07 +0000 Received: from blu0-omc1-s2.blu0.hotmail.com ([65.55.116.13]) by psg.com with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QFquD-000NoR-1F for radiusext@ops.ietf.org; Fri, 29 Apr 2011 16:51:01 +0000 Received: from BLU152-W6 ([65.55.116.9]) by blu0-omc1-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Apr 2011 09:50:59 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_881dc4af-09e1-44bb-a00e-2317a86e17a0_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS" Date: Fri, 29 Apr 2011 09:50:59 -0700 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2011 16:50:59.0726 (UTC) FILETIME=[9DF6E2E0:01CC068D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_881dc4af-09e1-44bb-a00e-2317a86e17a0_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an individual (chair hat off)=2C I have read the document and h= ave no issues.=20 From: bernard_aboba@hotmail.com To: radiusext@ops.ietf.org Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for= RADIUS" Date: Fri=2C 29 Apr 2011 09:43:39 -0700 This is a reminder of an ongoing RADEXT WG last call on "Crypto-Agility Req= uirements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-crypto-agility-requirements This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_881dc4af-09e1-44bb-a00e-2317a86e17a0_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an individual (chair hat off)=2C I have read the document and h= ave no issues.

From: bernard_aboba@hotmail.= com
To: radiusext@ops.ietf.org
Subject: REMINDER: RADEXT WG Last Cal= l on "Crypto-Agility Requirements for RADIUS"
Date: Fri=2C 29 Apr 2011 0= 9:43:39 -0700

This is a reminder of an ongoing RADEXT WG last call on "Crypto-Agility Requ= irements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =3B

The document is available for inspection here:

http://tools.ietf.org/= html/draft-ietf-radext-crypto-agility-requirements


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issues=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue = in TRAC=2C you first need to login to the RADEXT WG site on the tools serve= r: =3B http://tools.ietf.org/wg/radext/trac/login
2. =3B =3B =3B =3B =3B =3B If you don=92t alr= eady have a login ID=2C you can obtain one by navigating to this site: = =3B =3B http://trac.tools.ietf.org/newlogin

3. = =3B =3B =3B =3B =3B =3B Once you have obtained an accou= nt=2C and have logged in=2C you can file an issue by navigating to the = =3B ticket entry form: http://trac.tools.ietf.org/w= g/radext/trac/newticket

4. =3B =3B =3B =3B = =3B =3B When opening an issue:

a. =3B =3B =3B = =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1 =3B Click on t= he ticket # you want to update=2C and then modify the ticket fields as requ= ired

 =3B

= --_881dc4af-09e1-44bb-a00e-2317a86e17a0_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Apr 30 17:36:39 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573CEE06FB for ; Sat, 30 Apr 2011 17:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkise6YIE8kw for ; Sat, 30 Apr 2011 17:36:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 66029E06C0 for ; Sat, 30 Apr 2011 17:36:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QGKad-000Jvd-1v for radiusext-data0@psg.com; Sun, 01 May 2011 00:32:47 +0000 Received: from mail-vw0-f52.google.com ([209.85.212.52]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QGKaa-000JvS-GD for radiusext@ops.ietf.org; Sun, 01 May 2011 00:32:44 +0000 Received: by vws16 with SMTP id 16so5359273vws.11 for ; Sat, 30 Apr 2011 17:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=85bXQ255NIcUlN3bFdACk7pckMHVhV5aSnEEHeGLUx4=; b=lIfgdPJ+PPZH8PNvpwI9UX065QrIuYGhCnX79ZxodYsCi+WGRij8kJO6SPnBNAx/uO zntC4VFw9asDqZ7wfvedJd4S17j9ON6h/HmflxrpcPMoCWeLd5ZuVwwQGSED/jcyhpDP yNvrFfSnu+VHZy5SVSu+OXnojHS832gO3hLiY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=v8JqbAm795B4BECPoR/79RYOy3ieNlDSN7F5kd9ohPTMRqKq5FW9vM/mCkqrtapK3B 9fHycxlKvyYzQFG7vN2LZgo2rSnkmmdE6w/sx8kR0sjls9JavaMxA9fWaTuVSglNKT2D M/Hi3M1PhtTpCeHYtp+rGa2hpT5HGZ8w+Cf80= MIME-Version: 1.0 Received: by 10.52.93.107 with SMTP id ct11mr2438475vdb.243.1304209962152; Sat, 30 Apr 2011 17:32:42 -0700 (PDT) Received: by 10.52.186.227 with HTTP; Sat, 30 Apr 2011 17:32:42 -0700 (PDT) In-Reply-To: <4DB7BF30.6070002@deployingradius.com> References: <4DB7BF30.6070002@deployingradius.com> Date: Sun, 1 May 2011 08:32:42 +0800 Message-ID: Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00 From: Jacni Qin To: Alan DeKok Cc: Stefan Winter , radiusext@ops.ietf.org Content-Type: multipart/alternative; boundary=bcaec501638981b2a504a22c0bdc Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --bcaec501638981b2a504a22c0bdc Content-Type: text/plain; charset=ISO-8859-1 Re-, Ok, I got your point. Cheers, Jacni On Wed, Apr 27, 2011 at 3:01 PM, Alan DeKok wrote: > Jacni Qin wrote: > > * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall > > we "re-use" the type specified in RFC2866, like 245.1.47, etc. > > I would strongly recommend not doing that. Re-using the type would > lead people to conclude that the type space for TLVs is the same as the > type space for "normal" RADIUS attributes. This is not the case. > > Alan DeKok. > --bcaec501638981b2a504a22c0bdc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Re-,

Ok, I got your point.

=
Cheers,
Jacni

On Wed, Apr 2= 7, 2011 at 3:01 PM, Alan DeKok <aland@deployingradius.com><= /span> wrote:
Jacni Qin wrote:
> * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), S= hall
> we "re-use" the type specified in RFC2866, like 245.1.47, et= c.

=A0I would strongly recommend not doing that. =A0Re-using the type w= ould
lead people to conclude that the type space for TLVs is the same as the
type space for "normal" RADIUS attributes. =A0This is not the cas= e.

=A0Alan DeKok.

--bcaec501638981b2a504a22c0bdc-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Apr 30 17:38:07 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20DAE06AF for ; Sat, 30 Apr 2011 17:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.965 X-Spam-Level: X-Spam-Status: No, score=-2.965 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhTA7fKivbjW for ; Sat, 30 Apr 2011 17:38:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA16E0593 for ; Sat, 30 Apr 2011 17:38:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QGKe8-000KMV-DQ for radiusext-data0@psg.com; Sun, 01 May 2011 00:36:24 +0000 Received: from mail-vw0-f52.google.com ([209.85.212.52]) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QGKe4-000KLo-MI for radiusext@ops.ietf.org; Sun, 01 May 2011 00:36:20 +0000 Received: by vws16 with SMTP id 16so5360485vws.11 for ; Sat, 30 Apr 2011 17:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RvxJGUmD97Y6UzAhKjzloqi3NRegvGligqEG3xVLeXQ=; b=kkMhg+CBHlDHeN1SmT57piPkVCFt2EzAzwOUt1F/P0TY8mHNbxxJNPVfHtIBpzNRMF N/Q93rkwmB/KTHnw/zum33SOhf91s+voTvISppQsABAFcW5FbmoIjDWVtzTCR9gnId9v PFMxWqc0IBHa+qPlcTVqOFG/Sga+vo+edZ1aM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n6S0NcN4a8DIV0jAdcjEmCjIWIn2bfPOs1a8WlRu663mKBE0P0MUDFvKj1LQUuR23z 3WtKsFV5/qme8mZnDM5Y1jSFdQc+fw3roeLE2KczhQptBpi2w3ZpLK0bNNADRRlkQv7m 1Y1UVOD9+yCREOVmRVOhtLMns//GWjmAOyyKs= MIME-Version: 1.0 Received: by 10.52.176.41 with SMTP id cf9mr6172321vdc.123.1304210179455; Sat, 30 Apr 2011 17:36:19 -0700 (PDT) Received: by 10.52.186.227 with HTTP; Sat, 30 Apr 2011 17:36:19 -0700 (PDT) In-Reply-To: <4DB7E768.8070302@restena.lu> References: <4DB7E768.8070302@restena.lu> Date: Sun, 1 May 2011 08:36:19 +0800 Message-ID: Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00 From: Jacni Qin To: Stefan Winter Cc: radiusext@ops.ietf.org Content-Type: multipart/alternative; boundary=20cf3071c6fe757aba04a22c187c Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --20cf3071c6fe757aba04a22c187c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi, Sorry for my late reply, On Wed, Apr 27, 2011 at 5:52 PM, Stefan Winter wr= ote: > Hi, > > > I skimed the draft and got some comments, see below please. > > > > * "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to be > > redundant, I perfer to only keep the Name attribute which is STRING > > formatted and defined by BNG (configurable). The traffic classes are > > specified based on the capability of the BNG. No further IANA > > activities are needed in the future. > > It's true that any value expressed in -Id could also be formulated in a > string in -Name. However, naming conventions for the string are likely > to differ, so I would prefer to have controlled vocabulary at least for > more common use cases - like DSCP classes or IP versions, as in the draft= . > Jacni>: While we opened the door in this way for additional IANA activities. I have a fear that everytime we will need to request a value fo= r -id, then give the recommended definition of -name accordingly, and vise versa? ;-) > Another option would be to follow Alan's comment regarding > NAS-Filter-Rule naming. I'm not much of fan of this, because the first > examples which came to my mind: IP versions, DSCP values, don't sit > together in IPFilterRule (which is the basis for NAS-Filter-Rule). Only > IP versions could be expressed as a filter with NAS-Filter-Rule, but > DSCP is a Diameter QoSFilterRule - which can't be expressed in > NAS-Filter-Rule (I'll be happy to be corrected if I'm wrong here). > > > * An attribute similar to Type#44 Acct-Session-Id is necessary, since > > this is widely implemented in practice, for example, as an > > identification of user for policy changes initiated by AAA server. > > Name it "Acct-Traffic-Class-Id"? But the value should be a random > > number assigned by BNG. Some other attributes may also need to be > > considered. > > The example in the draft only shows a fragment of the entire Accounting > packet. The Accounting packet will be able to contain the > Acct-Session-Id, and then additionally one or more groups of > Accounting-Traffic-Group. > > I don't see an issue with that unless one would want to have different > session Id's for different traffic groups in the same accounting ticket > - but I have a hard time thinking of a reason for that; after all all > the counted Octets and Packets belong to the same user session, and can > thus share the same session id. > Jacni>: For example, two clasess v4 and v6, over single access service, there may be cases that the dynamic QoS or bandwidth policy changes (class-specific) are requested by users,say, through portal, then initiate/executed by the server side, the -id is needed. Cheers, Jacni > Greetings, > > Stefan Winter > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de > la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > > --20cf3071c6fe757aba04a22c187c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

Sorry for my late reply,

On Wed, Apr 27, 2011 at 5:52 PM, Stefan= Winter <stefan.winter@restena.lu> wrote:
Hi,

> I skimed the draft and got some comments, see below please.
>
> * "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to b= e
> redundant, I perfer to only keep the Name attribute which is STRING > formatted and defined by BNG (configurable). The traffic classes are > specified based on the capability of the BNG. No further IANA
> activities are needed in the future.

It's true that any value expressed in -Id could also be formulate= d in a
string in -Name. However, naming conventions for the string are likely
to differ, so I would prefer to have controlled vocabulary at least for
more common use cases - like DSCP classes or IP versions, as in the draft.<= br>

Jacni>: While= we opened the door in this way for additional IANA
activities. I have a= fear that everytime we will need to request a value for -id,
then give the recommended definition of -name accordingly, and vise versa? = ;-)


Another option would be to follow Alan's comment regarding
NAS-Filter-Rule naming. I'm not much of fan of this, because the first<= br> examples which came to my mind: IP versions, DSCP values, don't sit
together in IPFilterRule (which is the basis for NAS-Filter-Rule). Only
IP versions could be expressed as a filter with NAS-Filter-Rule, but
DSCP is a Diameter QoSFilterRule - which can't be expressed in
NAS-Filter-Rule (I'll be happy to be corrected if I'm wrong here).<= br>

> * An attribute similar to Type#44 Acct-Session-Id is necessary, since<= br> > this is widely implemented in practice, for example, as an
> identification of user for policy changes initiated by AAA server.
> Name it "Acct-Traffic-Class-Id"? But the value should be a r= andom
> number assigned by BNG. Some other attributes may also need to be
> considered.

The example in the draft only shows a fragment of the entire Accounti= ng
packet. The Accounting packet will be able to contain the
Acct-Session-Id, and then additionally one or more groups of
Accounting-Traffic-Group.

I don't see an issue with that unless one would want to have different<= br> session Id's for different traffic groups in the same accounting ticket=
- but I have a hard time thinking of a reason for that; after all all
the counted Octets and Packets belong to the same user session, and can
thus share the same session id.

Jacni>: For example, two clasess v4 and v6, over single = access service,
there may be cases that the dynamic QoS or bandwidth pol= icy changes (class-specific)
are requested by users,say, through portal, then initiate/executed by the s= erver side, the
-id is needed.


Cheers,
Jacni


Greetings,

Stefan Winter

--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nation= ale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473



--20cf3071c6fe757aba04a22c187c-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 29 Apr 2011 16:51:19 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_881dc4af-09e1-44bb-a00e-2317a86e17a0_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RE: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS" Date: Fri, 29 Apr 2011 09:50:59 -0700 MIME-Version: 1.0 --_881dc4af-09e1-44bb-a00e-2317a86e17a0_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an individual (chair hat off)=2C I have read the document and h= ave no issues.=20 From: bernard_aboba@hotmail.com To: radiusext@ops.ietf.org Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for= RADIUS" Date: Fri=2C 29 Apr 2011 09:43:39 -0700 This is a reminder of an ongoing RADEXT WG last call on "Crypto-Agility Req= uirements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-crypto-agility-requirements This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_881dc4af-09e1-44bb-a00e-2317a86e17a0_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Speaking as an individual (chair hat off)=2C I have read the document and h= ave no issues.

From: bernard_aboba@hotmail.= com
To: radiusext@ops.ietf.org
Subject: REMINDER: RADEXT WG Last Cal= l on "Crypto-Agility Requirements for RADIUS"
Date: Fri=2C 29 Apr 2011 0= 9:43:39 -0700

This is a reminder of an ongoing RADEXT WG last call on "Crypto-Agility Requ= irements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =3B

The document is available for inspection here:

http://tools.ietf.org/= html/draft-ietf-radext-crypto-agility-requirements


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issues=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue = in TRAC=2C you first need to login to the RADEXT WG site on the tools serve= r: =3B http://tools.ietf.org/wg/radext/trac/login
2. =3B =3B =3B =3B =3B =3B If you don=92t alr= eady have a login ID=2C you can obtain one by navigating to this site: = =3B =3B http://trac.tools.ietf.org/newlogin

3. = =3B =3B =3B =3B =3B =3B Once you have obtained an accou= nt=2C and have logged in=2C you can file an issue by navigating to the = =3B ticket entry form: http://trac.tools.ietf.org/w= g/radext/trac/newticket

4. =3B =3B =3B =3B = =3B =3B When opening an issue:

a. =3B =3B =3B = =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1 =3B Click on t= he ticket # you want to update=2C and then modify the ticket fields as requ= ired

 =3B

= --_881dc4af-09e1-44bb-a00e-2317a86e17a0_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 29 Apr 2011 16:49:50 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Fri, 29 Apr 2011 16:49:32 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #94: Compliance with Crypto-Agility Requirements Message-ID: <066.ae2e3be1fcc1e6f3414e9b5a3033cc0c@trac.tools.ietf.org> #94: Compliance with Crypto-Agility Requirements The Crypto-Agility Requirements document now in WG last call (see http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements ) includes the following in Section 1.4: In the initial phase, crypto-agility solutions adopted by the working group will be published on the Experimental Track. Experimental Track documents should contain a description of experimental deployments and implementations in progress, as well as an evaluation of the proposal against the requirements described in this document. The RDTLS document currently does not include this information. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 29 Apr 2011 16:49:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Fri, 29 Apr 2011 16:48:51 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #93: Compliance with Crypto-Agility Requirements Message-ID: <066.cbbe14ddeb8841047bdcf9c9dd8d3d7b@trac.tools.ietf.org> #93: Compliance with Crypto-Agility Requirements The Crypto-Agility Requirements document now in WG last call (see http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements ) includes the following in Section 1.4: In the initial phase, crypto-agility solutions adopted by the working group will be published on the Experimental Track. Experimental Track documents should contain a description of experimental deployments and implementations in progress, as well as an evaluation of the proposal against the requirements described in this document. The RADSEC document currently does not include this information. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 29 Apr 2011 16:43:58 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_d96f528a-16a4-46d4-b2c6-e683fb7d9087_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: REMINDER: RADEXT WG Last Call on "Crypto-Agility Requirements for RADIUS" Date: Fri, 29 Apr 2011 09:43:39 -0700 MIME-Version: 1.0 --_d96f528a-16a4-46d4-b2c6-e683fb7d9087_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a reminder of an ongoing RADEXT WG last call on "Crypto-Agility Req= uirements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-crypto-agility-requirements This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_d96f528a-16a4-46d4-b2c6-e683fb7d9087_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

This is a reminder of an ongoing RADE= XT WG last call on "Crypto-A= gility Requirements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =3B

The document is available for inspection here:

= http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issu= es=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue in = TRAC=2C you first need to login to the RADEXT WG site on the tools server:&= nbsp=3B http://tools.ietf.org/wg/radext/trac/login

2. =3B = =3B =3B =3B =3B =3B If you don=92t already have a login ID= =2C you can obtain one by navigating to this site: =3B =3B http://trac.tool= s.ietf.org/newlogin

3. =3B =3B =3B =3B =3B&n= bsp=3B Once you have obtained an account=2C and have logged in=2C you can f= ile an issue by navigating to the =3B ticket entry form: http://t= rac.tools.ietf.org/wg/radext/trac/newticket

4. =3B =3B&n= bsp=3B =3B =3B =3B When opening an issue:

a. =3B&nbs= p=3B =3B =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tool= s.ietf.org/wg/radext/trac/report/1 =3B Click on the ticket # you wa= nt to update=2C and then modify the ticket fields as required

 =3B

= = --_d96f528a-16a4-46d4-b2c6-e683fb7d9087_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 29 Apr 2011 16:43:49 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_1c19f56d-0343-447e-857a-8bfeec71138d_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: REMINDER: RADEXT WG Last Call on "TLS encryption for RADIUS" Date: Fri, 29 Apr 2011 09:42:30 -0700 MIME-Version: 1.0 --_1c19f56d-0343-447e-857a-8bfeec71138d_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a reminder of an ongoing RADEXT WG last call on "TLS encryption fo= r RADIUS"=2C prior to sending the document to the IESG for publication as an Experiment= al RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-radsec This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_1c19f56d-0343-447e-857a-8bfeec71138d_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This = is a reminder of an ongoing =3B RADEXT WG last call on "TLS encryption fo= r RADIUS"=2C prior to sending the document to the IESG for publication as an Experiment= al RFC. =3B


The document is available for inspection here= :<= /p>

http://tools.ietf= .org/html/draft-ietf-radext-radsec


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issues=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue = in TRAC=2C you first need to login to the RADEXT WG site on the tools serve= r: =3B http://tools.ietf.org/wg/radext/trac/login
2. =3B =3B =3B =3B =3B =3B If you don=92t alr= eady have a login ID=2C you can obtain one by navigating to this site: = =3B =3B http://trac.tools.ietf.org/newlogin

3. = =3B =3B =3B =3B =3B =3B Once you have obtained an accou= nt=2C and have logged in=2C you can file an issue by navigating to the = =3B ticket entry form: http://trac.tools.ietf.org/w= g/radext/trac/newticket

4. =3B =3B =3B =3B = =3B =3B When opening an issue:

a. =3B =3B =3B = =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1 =3B Click on t= he ticket # you want to update=2C and then modify the ticket fields as requ= ired

 =3B

= --_1c19f56d-0343-447e-857a-8bfeec71138d_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 28 Apr 2011 10:31:31 +0000 Message-ID: <4DB941B6.5010509@deployingradius.com> Date: Thu, 28 Apr 2011 12:30:14 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon CC: radiusext@ops.ietf.org Subject: Re: Byte counting in draft-winter-radext-fancyaccounting-00 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Deacon wrote: > There is sometimes confusion (For me anyway) regarding what counters > actually count. Traditionally Input/Output octets are protocol agnostic > and just count low layer bits shuffled between interfaces. > > Lets say we run IPv6 over PPP or Ethernet do the byte counts apply only > to the higher layer IP frames and not a lower layer ethernet or PPP frame? I'd say it's still bits over the interface, including ethernet or PPP. > Alternately if there was a traffic class for even higher layer messages > such as HTTP..does it count the HTTP layer only or the IP header and > possibly ethernet/PPP header? We can define traffic classes for all of that, I think. > I don't really have an opinion on the behavior only that it would be > best if all implementations stand a good chance of counting the same way. The specification needs to be clear on what is being counted. It would help to have specific examples of this in the doc. e.g. If the description is "HTTP traffic on port 80", then the data being counted should be *only* HTTP, not lower-layer TCP, IP, etc. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 27 Apr 2011 17:35:35 +0000 Date: Wed, 27 Apr 2011 10:34:30 -0700 (Pacific Daylight Time) From: Peter Deacon To: radiusext@ops.ietf.org Subject: Byte counting in draft-winter-radext-fancyaccounting-00 Message-ID: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed There is sometimes confusion (For me anyway) regarding what counters actually count. Traditionally Input/Output octets are protocol agnostic and just count low layer bits shuffled between interfaces. Lets say we run IPv6 over PPP or Ethernet do the byte counts apply only to the higher layer IP frames and not a lower layer ethernet or PPP frame? Alternately if there was a traffic class for even higher layer messages such as HTTP..does it count the HTTP layer only or the IP header and possibly ethernet/PPP header? I don't really have an opinion on the behavior only that it would be best if all implementations stand a good chance of counting the same way. regards, Peter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 27 Apr 2011 09:53:05 +0000 Message-ID: <4DB7E768.8070302@restena.lu> Date: Wed, 27 Apr 2011 11:52:40 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Jacni Qin CC: radiusext@ops.ietf.org Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig77C67CB06BF2D8390988954F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig77C67CB06BF2D8390988954F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I skimed the draft and got some comments, see below please. > > * "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to be > redundant, I perfer to only keep the Name attribute which is STRING > formatted and defined by BNG (configurable). The traffic classes are > specified based on the capability of the BNG. No further IANA > activities are needed in the future. It's true that any value expressed in -Id could also be formulated in a string in -Name. However, naming conventions for the string are likely to differ, so I would prefer to have controlled vocabulary at least for more common use cases - like DSCP classes or IP versions, as in the draft= =2E Another option would be to follow Alan's comment regarding NAS-Filter-Rule naming. I'm not much of fan of this, because the first examples which came to my mind: IP versions, DSCP values, don't sit together in IPFilterRule (which is the basis for NAS-Filter-Rule). Only IP versions could be expressed as a filter with NAS-Filter-Rule, but DSCP is a Diameter QoSFilterRule - which can't be expressed in NAS-Filter-Rule (I'll be happy to be corrected if I'm wrong here). > * An attribute similar to Type#44 Acct-Session-Id is necessary, since > this is widely implemented in practice, for example, as an > identification of user for policy changes initiated by AAA server. > Name it "Acct-Traffic-Class-Id"? But the value should be a random > number assigned by BNG. Some other attributes may also need to be > considered. The example in the draft only shows a fragment of the entire Accounting packet. The Accounting packet will be able to contain the Acct-Session-Id, and then additionally one or more groups of Accounting-Traffic-Group. I don't see an issue with that unless one would want to have different session Id's for different traffic groups in the same accounting ticket - but I have a hard time thinking of a reason for that; after all all the counted Octets and Packets belong to the same user session, and can thus share the same session id. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig77C67CB06BF2D8390988954F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2352sACgkQ+jm90f8eFWbUCgCfUNBOk/HzVGPfbpqnws1syOW1 lhYAnibhTsblIhE1yNIQDBPAXuRlkPNb =ppBx -----END PGP SIGNATURE----- --------------enig77C67CB06BF2D8390988954F-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 27 Apr 2011 09:40:20 +0000 Message-ID: <4DB7E450.4050400@restena.lu> Date: Wed, 27 Apr 2011 11:39:28 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alan DeKok CC: Jacni Qin , radiusext@ops.ietf.org Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0274F0312503D2C55C686DB4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0274F0312503D2C55C686DB4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall= >> we "re-use" the type specified in RFC2866, like 245.1.47, etc. > I would strongly recommend not doing that. Re-using the type would > lead people to conclude that the type space for TLVs is the same as the= > type space for "normal" RADIUS attributes. This is not the case. Also, the data types used here are actually *different* (64 bit integer). Giving them the same number as an already existing attribute with a mismatching data types invites sloppiness errors in implementation= s. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig0274F0312503D2C55C686DB4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk235FAACgkQ+jm90f8eFWaXEwCfSRZTQyX5u42L5/WjeGUJYm9r 924An3LpbxZoTAletcOvAf6UBx6+E6jS =9bbJ -----END PGP SIGNATURE----- --------------enig0274F0312503D2C55C686DB4-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 27 Apr 2011 07:01:41 +0000 Message-ID: <4DB7BF30.6070002@deployingradius.com> Date: Wed, 27 Apr 2011 09:01:04 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jacni Qin CC: Stefan Winter , radiusext@ops.ietf.org Subject: Re: Some comments on draft-winter-radext-fancyaccounting-00 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jacni Qin wrote: > * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall > we "re-use" the type specified in RFC2866, like 245.1.47, etc. I would strongly recommend not doing that. Re-using the type would lead people to conclude that the type space for TLVs is the same as the type space for "normal" RADIUS attributes. This is not the case. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 27 Apr 2011 06:19:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=PdvtIWEjOeskUKAv3Njvo8Xr5BonH1rUzQ7651kxzvQ=; b=ngcy/X7Wq8SER5h2YNkb0yh9M0PiI2pwCBOSI1wFHiq9Ch+Gq2PO3wcoap01y+Fgij RTCgtinqN2l6E9nMHksGQrVr3puj0Dc/Zh91/S1/Z+z9Cc1FL3f1N8iEEe66EKG1QDAa a+CTkrrQ1JRIpnX4+cnevxpwC2tV7ZMgPzh40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=C/Ku8rsJkZsOGYJB4SAx41Qbj36aIUOw8C++h1Rg/OWfoIUF/aVnGSDEcYnn+agxyI 67MG0S4dYxTNj15ofXC6xxkvdPb/CfpMwTQeYnPAOC9MxJr3tMsMP+kptWD+OOurb9Qj Yv+45OpnhJTB2reP8VV5VBzXi1oDGVnAJeiic= MIME-Version: 1.0 Date: Wed, 27 Apr 2011 14:18:09 +0800 Message-ID: Subject: Some comments on draft-winter-radext-fancyaccounting-00 From: Jacni Qin To: Stefan Winter Cc: radiusext@ops.ietf.org Content-Type: multipart/alternative; boundary=0016e68e8d2890e32c04a1e0679e --0016e68e8d2890e32c04a1e0679e Content-Type: text/plain; charset=ISO-8859-1 Dear Stefan & all, I skimed the draft and got some comments, see below please. * "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to be redundant, I perfer to only keep the Name attribute which is STRING formatted and defined by BNG (configurable). The traffic classes are specified based on the capability of the BNG. No further IANA activities are needed in the future. * For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall we "re-use" the type specified in RFC2866, like 245.1.47, etc. * An attribute similar to Type#44 Acct-Session-Id is necessary, since this is widely implemented in practice, for example, as an identification of user for policy changes initiated by AAA server. Name it "Acct-Traffic-Class-Id"? But the value should be a random number assigned by BNG. Some other attributes may also need to be considered. Or, I can propose some text if you want. Cheers, Jacni --0016e68e8d2890e32c04a1e0679e Content-Type: text/html; charset=ISO-8859-1 Dear Stefan & all,

I skimed the draft and got some comments, see below please.

* "Section 2.2.1.Acct-Traffic-Class-Id attribute" seems to be redundant, I perfer to only keep the Name attribute which is STRING formatted and defined by BNG (configurable). The traffic classes are specified based on the capability of the BNG. No further IANA activities are needed in the future.

* For the Input-* & Output-* attributes (Section 2.2.3 ~ 2.2.6), Shall we "re-use" the type specified in RFC2866, like 245.1.47, etc.

* An attribute similar to Type#44 Acct-Session-Id is necessary, since this is widely implemented in practice, for example, as an identification of user for policy changes initiated by AAA server. Name it "Acct-Traffic-Class-Id"? But the value should be a random number assigned by BNG. Some other attributes may also need to be considered.

Or, I can propose some text if you want.


Cheers,
Jacni


 --0016e68e8d2890e32c04a1e0679e-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 20 Apr 2011 22:26:03 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_43da1465-a057-4a42-9144-1fb483464990_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Re: WG Last Call on "Crypto-Agility Requirements for RADIUS" Date: Wed, 20 Apr 2011 15:24:59 -0700 MIME-Version: 1.0 --_43da1465-a057-4a42-9144-1fb483464990_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking as an individual=2C I have read this draft and feel it is suitabl= e for publication. I have no specific comments to make at this time.=20 = --_43da1465-a057-4a42-9144-1fb483464990_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking as an individual=2C I =3B have re= ad this draft and feel it is suitable for publication. =3B =3B I ha= ve no specific comments to make at this time.


= --_43da1465-a057-4a42-9144-1fb483464990_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 17 Apr 2011 19:37:07 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_ee60a55a-079c-4f84-8c1c-8d978797240e_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: WG Last Call on "TLS encryption for RADIUS" Date: Sun, 17 Apr 2011 12:36:36 -0700 MIME-Version: 1.0 --_ee60a55a-079c-4f84-8c1c-8d978797240e_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on "TLS encryption for RADIU= S"=2C prior to sending the document to the IESG for publication as an Experiment= al RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-radsec This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_ee60a55a-079c-4f84-8c1c-8d978797240e_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This = is an announcement of RADEXT WG last call on "TLS encryption for RADIUS"=2C prior to sending the document to the IESG for publication as an Experiment= al RFC. =3B


The document is available for inspection here= :<= /p>

http://tools.ietf= .org/html/draft-ietf-radext-radsec


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issues=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue = in TRAC=2C you first need to login to the RADEXT WG site on the tools serve= r: =3B http://tools.ietf.org/wg/radext/trac/login
2. =3B =3B =3B =3B =3B =3B If you don=92t alr= eady have a login ID=2C you can obtain one by navigating to this site: = =3B =3B http://trac.tools.ietf.org/newlogin

3. = =3B =3B =3B =3B =3B =3B Once you have obtained an accou= nt=2C and have logged in=2C you can file an issue by navigating to the = =3B ticket entry form: http://trac.tools.ietf.org/w= g/radext/trac/newticket

4. =3B =3B =3B =3B = =3B =3B When opening an issue:

a. =3B =3B =3B = =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1 =3B Click on t= he ticket # you want to update=2C and then modify the ticket fields as requ= ired

 =3B

= --_ee60a55a-079c-4f84-8c1c-8d978797240e_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 17 Apr 2011 19:25:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: stefan.winter@restena.lu, bernard_aboba@hotmail.com Date: Sun, 17 Apr 2011 19:25:06 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #3: Review of RTLS document (part 1, Technical) Message-ID: <075.818a0c8b1c31772a342e7a4561487ffe@trac.tools.ietf.org> #3: Review of RTLS document (part 1, Technical) Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 17 Apr 2011 19:01:53 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_5899b8ec-59e8-445e-95f1-061d17174ca0_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: WG Last Call on "Crypto-Agility Requirements for RADIUS" Date: Sun, 17 Apr 2011 12:00:58 -0700 MIME-Version: 1.0 --_5899b8ec-59e8-445e-95f1-061d17174ca0_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on "Crypto-Agility Requireme= nts for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =20 The document is available for inspection here:http://tools.ietf.org/html/dr= aft-ietf-radext-crypto-agility-requirements This RADEXT WG last call will last until May 1=2C 2011. If you have=20 comments on the document=2C please file them using the TRAC system. If you= read the draft and have no issues=2C please state this on the mailing list. See below for=20 summary of instructions. 1. To submit an issue in TRAC=2C you first = need to login to the RADEXT WG site on the tools server: http://tools.ietf= .org/wg/radext/trac/login=20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_5899b8ec-59e8-445e-95f1-061d17174ca0_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

This is an announcement of RADEXT WG = last call on "Crypto-Agili= ty Requirements for RADIUS"=2C prior to sending the document to the IESG for publication as an Informatio= nal RFC. =3B

The document is available for inspection here:

= http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements


This RADEXT WG last call will last until May 1=2C 2011. =3B =3B If you = have=20 comments on the document=2C please file them using the TRAC system. =3B= If you read the draft and have no issu= es=2C please state this on the mailing list. =3B See below for=20 summary of instructions.

 =3B

1. =3B =3B =3B =3B =3B =3B To submit an issue in = TRAC=2C you first need to login to the RADEXT WG site on the tools server:&= nbsp=3B http://tools.ietf.org/wg/radext/trac/login

2. =3B = =3B =3B =3B =3B =3B If you don=92t already have a login ID= =2C you can obtain one by navigating to this site: =3B =3B http://trac.tool= s.ietf.org/newlogin

3. =3B =3B =3B =3B =3B&n= bsp=3B Once you have obtained an account=2C and have logged in=2C you can f= ile an issue by navigating to the =3B ticket entry form: http://t= rac.tools.ietf.org/wg/radext/trac/newticket

4. =3B =3B&n= bsp=3B =3B =3B =3B When opening an issue:

a. =3B&nbs= p=3B =3B =3B =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tool= s.ietf.org/wg/radext/trac/report/1 =3B Click on the ticket # you wa= nt to update=2C and then modify the ticket fields as required

 =3B

= = --_5899b8ec-59e8-445e-95f1-061d17174ca0_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 17 Apr 2011 13:01:16 +0000 MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-05.txt Message-ID: <20110417130001.5280.63645.idtracker@ietfc.amsl.com> Date: Sun, 17 Apr 2011 06:00:01 -0700 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Author(s) : D. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-05.txt Pages : 11 Date : 2011-04-16 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-crypto-agility-requirements-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-17054858.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 17 Apr 2011 02:28:15 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 17 Apr 2011 02:27:58 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #90: Process for publication and selection Message-ID: <075.0132e29ebbe223e3f7b71c25d86ee288@trac.tools.ietf.org> #90: Process for publication and selection Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is to add a Section 1.4 as follows: 1.4. Publication Process RADIUS [RFC2865] is a widely deployed protocol that has attained Draft Standard status based on multiple independent interoperable implementations. It is therefore highly desirable that a high level of interoperability and security be maintained for crypto-agility solutions. To ensure that crypto-agility solutions published on the standards track are well specified, secure and interoperable, the RADEXT WG has adopted a two phase process for publication of crypto-agility solutions. In the initial phase, crypto-agility solutions adopted by the working group will be published on the Experimental Track. Experimental Track documents should contain a description of experimental deployments and implementations in progress, as well as an evaluation of the proposal against the requirements described in this document. Based on the proposal evaluations, implementation and deployment experience, and the results of interoperability tests, initial proposals will be evaluated for publication on the standards track. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 17 Apr 2011 02:27:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 17 Apr 2011 02:25:49 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #92: End-to-end versus hop-by-hop confidentiality Message-ID: <075.878c7b191c9a26e9c0cd13413cba225b@trac.tools.ietf.org> #92: End-to-end versus hop-by-hop confidentiality Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 13 Apr 2011 12:20:38 +0000 From: Avi Lior To: Dave Nelson CC: "Sanchez, Mauricio (HP Networking)" , "radiusext@ops.ietf.org" Date: Wed, 13 Apr 2011 08:19:32 -0400 Subject: Re: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acv51RQYZ7+waTcFQt6WuN3OZAao8g== Message-ID: Accept-Language: en-US Content-Language: en-US user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 See inline... -- Avi Lior --Bridgewater Systems On 13-04-11 13:27 , "Dave Nelson" wrote: >On Wed, Apr 13, 2011 at 6:43 AM, Avi Lior >wrote: > >> The finest granularity is the "Port" or the connection or the service >>the >> is being authenticated/authorized. > >Yes. Do you envision a situation where a single NAS would report an a >802.11 port type on one connection ans a WiMAX-802.11 port type on >another connection? Actually yes. Imagine if you will a web server that is authenticating users for WiFi and one that is authenticating user for something else. My point is that if I only worry about the "ports" instead of the NAS, I couldn't possibly fall into a "trap" later on. The trap being the assumption that a NAS is homogeneous. The question then becomes what benefit(s) do I get for treating the NAS as a homogeneous set of ports. > Or would the NAS only report various combinations >of WiMAX specific connections? > >> In any case, the NAS-Port-Type is good enough. > >Yeah, a lot of things we do with RADIUS are "good enough", even if >they are not completely correct, in terms of a coherent >object-oriented data model. I'm not endorsing that behavior, just >taking note of it. > >Regards, > >Dave > >David B. Nelson >Sr. Software Architect >Elbrys Networks, Inc. >www.elbrys.com >+1.603.570.2636 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 13 Apr 2011 10:44:34 +0000 From: Avi Lior To: Dave Nelson CC: "Sanchez, Mauricio (HP Networking)" , "radiusext@ops.ietf.org" Date: Wed, 13 Apr 2011 06:43:12 -0400 Subject: Re: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acv5x5d9c2F6BJ6YREKfKqbqFBjm2g== Message-ID: Accept-Language: en-US Content-Language: en-US user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Dave, Thanks for your comments. On 11-04-11 14:46 , "Dave Nelson" wrote: >On Mon, Apr 11, 2011 at 6:24 AM, Avi Lior >wrote: > >> WiMAX decided that it want an explicit indication of the type of NAS >>and hence wants to use the NAS-Port-Type to determine the context of the >>call. > >In other words, using NAS-Port-Type to mean NAS-Type. If the >properties of the port itself are the same, this seems confusing. >Maybe what's needed is a NAS-Type attribute? I still think its a NAS-Port-Type. A given NAS may have different NAS-Port-Types or more to the point, offer more then one type of connection/service. The finest granularity is the "Port" or the connection or the service the is being authenticated/authorized. In any case, the NAS-Port-Type is good enough. I don't think we need to invent another thing. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 12 Apr 2011 07:22:05 +0000 Date: Tue, 12 Apr 2011 07:19:26 +0000 From: Jiangsheng Subject: RE: 6rd attribute compromise? To: Alan DeKok , Peter Deacon Cc: radiusext Message-id: <5D36713D8A4E7348A7E10DF7437A4B9282C2D3@SZXEML504-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: 6rd attribute compromise? Thread-index: AQHL+N7y9/vyP9NEykaaS1J8YmjSDpRZRrSAgACKlMA= OK, I will put the reserved byte back. I will wait another two or three days in case there are other comments, then update a new version with the new TLVs. After that, softwire chair will probably launch the WGLC on both softwire and radext wg mail list. :) Many thanks, Sheng > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Alan DeKok > Sent: Tuesday, April 12, 2011 3:00 PM > To: Peter Deacon > Cc: Jiangsheng; radiusext > Subject: Re: 6rd attribute compromise? > > Peter Deacon wrote: > > Hi Jiangsheng, just included reserved /w ascii example to be a closer > > match to the existing attribute format for prefix (RFC 3162 2.3) > > I agree with Peter here. Leaving the reserved byte in place allows > many RADIUS servers to use these new attributes with only a dictionary > update. > > Deleting the reserved byte means that the IPv6 prefix for 6rd has a > different format than for all other IPv6 prefix attributes. > > Alan DeKok. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 12 Apr 2011 07:01:06 +0000 Message-ID: <4DA3F881.8030607@deployingradius.com> Date: Tue, 12 Apr 2011 09:00:17 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon CC: Jiangsheng , radiusext Subject: Re: 6rd attribute compromise? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Deacon wrote: > Hi Jiangsheng, just included reserved /w ascii example to be a closer > match to the existing attribute format for prefix (RFC 3162 2.3) I agree with Peter here. Leaving the reserved byte in place allows many RADIUS servers to use these new attributes with only a dictionary update. Deleting the reserved byte means that the IPv6 prefix for 6rd has a different format than for all other IPv6 prefix attributes. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 12 Apr 2011 06:51:44 +0000 Date: Mon, 11 Apr 2011 23:50:33 -0700 (Pacific Daylight Time) From: Peter Deacon To: Jiangsheng cc: Alan DeKok , radiusext Subject: Re: 6rd attribute compromise? Message-ID: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 12 Apr 2011, Jiangsheng wrote: > The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969. > > However, if this is not compatible with RADIUS, we would like to accept > any suggestion from RADEXT WG. So, the first question is whether our > current 6rd attr design is NOT acceptable by RADIUS. > If the answer is NO, Peter's suggestion looks good for us except why a > Reserved byte. Hi Jiangsheng, just included reserved /w ascii example to be a closer match to the existing attribute format for prefix (RFC 3162 2.3) regards, Peter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 12 Apr 2011 06:48:43 +0000 Date: Tue, 12 Apr 2011 06:47:17 +0000 From: Jiangsheng Subject: RE: 6rd attribute compromise? To: Alan DeKok Cc: Peter Deacon , radiusext Message-id: <5D36713D8A4E7348A7E10DF7437A4B9282C299@SZXEML504-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: 6rd attribute compromise? Thread-index: AQHL+NVNg0EtjQPRfU2ZBV7YAqmC45RZwdwg Hi, Alan, Thanks for your reply. It is much clearer now. After carefully read RFC 6158, we don't think the attribute can be referred to a pre-existing data format because this attribute should be parsed by the Radius server. In 6rd scenarios, it is the Radius server who manages the user configuration information. Therefore, this 6rd attribute can NOT "be treated as opaque data by the RADIUS server." So, it leaves TLVs the best choice. As the below, I slightly modified Peter's proposal by removing the Reserved byte. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SubType (1) | SubLen (3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4MaskLen | SubType (2) | SubLen (19) | 6rdPrefixLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 6rdPrefix | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubType (3) | SubLen (6) | 6rdBRIPv4Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6rdBRIPv4Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Any further comments? Peter, do you have any particular reasons to add the Reserved byte back? Sheng > -----Original Message----- > From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Alan DeKok > Sent: Tuesday, April 12, 2011 1:44 PM > To: Jiangsheng > Cc: Peter Deacon; radiusext > Subject: Re: 6rd attribute compromise? > > Jiangsheng wrote: > > The format design of this 6rd attribute was to be the same with 6rd > DHCPv4 Option, please see section 7.1.1 of RFC 5969. > > Please see RFC 6158, Section 3.2.4. If you are transporting a > pre-defined data type in RADIUS, then don't re-define it in RADIUS. > Instead, just say "this attribute has the format as described in RFC > 5969 Section 7.1.1" > > > However, if this is not compatible with RADIUS, we would like to > accept any suggestion from RADEXT WG. So, the first question is whether > our current 6rd attr design is NOT acceptable by RADIUS. > > It does not follow the guidelines set down in RFC 6158. > > > If the answer is NO, Peter's suggestion looks good for us except why > a Reserved byte. > > I think using TLVs for this attribute would be a good choice, but not > necessarily better than referring to a pre-existing data format. > > > We do not understand Alan's third approach. Could Alan explain a > little bit more, "An alternative approach would be to publish a "new > data types" RFC, > > containing just TLV and 64-bit integer data types." And how this > relevant to our 6rd attribute? > > You could use the new data types in the document, rather than > inventing a data type which is incompatible with existing RADIUS > practice. > > Alan DeKok. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 12 Apr 2011 05:44:23 +0000 Message-ID: <4DA3E688.5040401@deployingradius.com> Date: Tue, 12 Apr 2011 07:43:36 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jiangsheng CC: Peter Deacon , radiusext Subject: Re: 6rd attribute compromise? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jiangsheng wrote: > The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969. Please see RFC 6158, Section 3.2.4. If you are transporting a pre-defined data type in RADIUS, then don't re-define it in RADIUS. Instead, just say "this attribute has the format as described in RFC 5969 Section 7.1.1" > However, if this is not compatible with RADIUS, we would like to accept any suggestion from RADEXT WG. So, the first question is whether our current 6rd attr design is NOT acceptable by RADIUS. It does not follow the guidelines set down in RFC 6158. > If the answer is NO, Peter's suggestion looks good for us except why a Reserved byte. I think using TLVs for this attribute would be a good choice, but not necessarily better than referring to a pre-existing data format. > We do not understand Alan's third approach. Could Alan explain a little bit more, "An alternative approach would be to publish a "new data types" RFC, > containing just TLV and 64-bit integer data types." And how this relevant to our 6rd attribute? You could use the new data types in the document, rather than inventing a data type which is incompatible with existing RADIUS practice. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 12 Apr 2011 03:27:45 +0000 Date: Tue, 12 Apr 2011 03:25:30 +0000 From: Jiangsheng Subject: Re: 6rd attribute compromise? To: Alan DeKok Cc: Peter Deacon , radiusext Message-id: <5D36713D8A4E7348A7E10DF7437A4B9282BA3F@SZXEML504-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: Re: 6rd attribute compromise? Thread-index: Acv4wUM7dE/ZV6sVSvu0/NYIa3QUdg== Hi, Alan and Peter, Sorry for the late reply. The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969. However, if this is not compatible with RADIUS, we would like to accept any suggestion from RADEXT WG. So, the first question is whether our current 6rd attr design is NOT acceptable by RADIUS. If the answer is NO, Peter's suggestion looks good for us except why a Reserved byte. The second choice could be we limit 6rdBRIPv4Address to be only 1 instance. Then we have a fixed length attribute. But this need to enable grouping multiple attributes module, which seems RADIUS protocol does not support currently. We do not understand Alan's third approach. Could Alan explain a little bit more, "An alternative approach would be to publish a "new data types" RFC, containing just TLV and 64-bit integer data types." And how this relevant to our 6rd attribute? Best regards, Sheng & Dayong -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Apr 2011 10:26:10 +0000 From: Avi Lior To: "Sanchez, Mauricio (HP Networking)" , "'radiusext@ops.ietf.org'" Date: Mon, 11 Apr 2011 06:24:37 -0400 Subject: Re: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acv4Mrx3Bi71uZxORzeaMPGsCKrocw== Message-ID: Accept-Language: en-US Content-Language: en-US user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9C89DCA1344Aavibridgewatersystemscom_" MIME-Version: 1.0 --_000_C9C89DCA1344Aavibridgewatersystemscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Regarding the below comments: - Stefan comments that there=92s already type for WiFi so not sure why anot= her one is needed, just one. - Klaas comments that agrees with Stefan=92s comments. - Nancy comments that looking at the current assignment is that there is on= ly 1 allocation per mode. Maybe it wasn't made clear why WiMAX requires these assignment. An email wa= s sent recently and also this was discussed previously on the RADEXT reflec= tor (See Nov. 2009). Briefly: The AAA in WiMAX is responsible to interact with various types of WiMAX NAS= es and also non-WiMAX NASes: The AAA thus needs to be able to determine wh= ich type of NAS it communicates with to determine the context of the Access= -Request. WiMAX decided that it want an explicit indication of the type of= NAS and hence wants to use the NAS-Port-Type to determine the context of t= he call. The question is whether or not the NAS-Port-Type is the attribute to be use= d for that. The answer seems to be yes. Second, the objection also seems to be based the number being requested. I= s there a shortage of numbers? I don't think so. This was also discussed = by the group in the past. -- Avi Lior --Bridgewater Systems On 08-04-11 14:30 , "Sanchez, Mauricio (HP Networking)" > wrote: During IETF 80 one of the agenda topics discussed was whether to approve a = request received by IANA for allocation of additional NAS-port-type values = relating to Wimax as described below Type of Assignment : Nas-Port-Type values as follows: TBD for WIMAX-3GPP-PRIF: WiMAX Pre-Release 8 IWK Function TBD for WIMAX-WIFI-IWK: WiMAX WIFI Interworking TBD for WIMAX-SFF: Signaling Forwarding Function for LTE/3GPP2. TBD for WIMAX-HA-LMA: WiMAX HA and or LMA function. TBD for WIMAX-DHCP : WIMAX DCHP service TBD for WIMAX- LBS : WiMAX location based service TBD for WIMAX-WVS : WiMAX voice service The snippet of meeting notes relating to this topic are show below: ---- --------------------------- Request for registration for NAS-port-type. Under 3575, falls under expert= review. This request is for NAS-port-type relating to WiMax - Stefan comments that there=92s already type for WiFi so not sure why anot= her one is needed, just one. - Klaas comments that agrees with Stefan=92s comments. - Nancy comments that looking at the current assignment is that there is on= ly 1 allocation per mode. - Bernard takes the general comment of only allocating one as the response = to take back to the request. Given consensus here, will verify that opinio= n in the reflector. ---- --------------------------- The sentiment in the room was clearly against approving this IANA request a= nd at this time we would like to confirm this on the mailing list. Please respond to this email and state whether you are in favor or against = approving this IANA request. Thanks, MS --_000_C9C89DCA1344Aavibridgewatersystemscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Regarding the below comments:

- Stefan comments th= at there=92s already type for WiFi so not sure why another one is needed, j= ust one.

- Klaas comments that agrees with Stef= an=92s comments.

- Nancy comments that looking = at the current assignment is that there is only 1 allocation per mode.=


Maybe it wasn't made clear wh= y WiMAX requires these assignment. An email was sent recently and also this= was discussed previously on the RADEXT reflector (See Nov. 2009).


Briefly:


The AAA in WiMAX is responsible to interact with various types of WiM= AX NASes and also non-WiMAX NASes:  The AAA thus needs to be able to d= etermine which type of NAS it communicates with to determine the context of= the Access-Request.  WiMAX decided that it want an explicit indicatio= n of the type of NAS and hence wants to use the NAS-Port-Type to determine = the context of the call.   



=

Second, the objection also seems to be based the number b= eing requested.  Is there a shortage of numbers?  I don't think s= o.  This was also discussed by the group in the past.




-- Avi L= ior
--Bridgewater Systems

<= /div>

On 08-04-11= 14:30 , "Sanchez, Mauricio (HP Networking)" <mauricio.sanchez@hp.com> wrote:

During IETF = 80 one of the agenda topics discussed was whether to approve a request rece= ived by IANA for allocation of additional NAS-port-type values relating to = Wimax as described below

 <= /o:p>

Type of Assignment :
Nas-Port-Type value= s as follows:
TBD for WIMAX-3GPP-PRIF:  WiMAX Pre-Release 8 IW= K Function
TBD for WIMAX-WIFI-IWK:  WiMAX   WIFI Interwor= king
TBD for WIMAX-SFF: Signaling Forwarding Function  for LTE= /3GPP2.
TBD for WIMAX-HA-LMA:  WiMAX HA and or LMA   = ;function.
TBD for WIMAX-DHCP : WIMAX DCHP service

TBD for WIMAX- LBS  : WiMAX location based servic= e
TBD for WIMAX-WVS : WiMAX  voice service

 

The snippet o= f meeting notes relating to this topic are show below:

 

---- <meeti= ng note snippet begin>---------------------------

 

Request for reg= istration for NAS-port-type.  Under 3575, falls under expert review.&n= bsp; This request is for NAS-port-type relating to WiMax

- Stefan comments that there=92s already type for WiFi s= o not sure why another one is needed, just one.

- Klaas comments that agrees with Stefan=92s comments.=

- Nancy comments that looking at the current ass= ignment is that there is only 1 allocation per mode.

- Bernard takes the general comment of only allocating one a= s the response to take back to the request.  Given consensus here, wil= l verify that opinion in the reflector.

 

---- <meeting note snippet= end>---------------------------

 

The sentiment in the room was cle= arly against approving this IANA request and at this time we would like to = confirm this on the mailing list.  

 

Please respond to this email= and state whether you are in favor or against approving this IANA request.=  

 

Thanks,

MS <= /p>

 

--_000_C9C89DCA1344Aavibridgewatersystemscom_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 11 Apr 2011 05:52:21 +0000 Message-ID: <4DA296C9.20301@restena.lu> Date: Mon, 11 Apr 2011 07:51:05 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alper Yegin CC: "'Sanchez, Mauricio \(HP Networking\)'" , radiusext@ops.ietf.org Subject: Re: Consensus poll for IANA #409959 NAS-Port-Type value request Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8C3133073BC9630676D8BC63" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8C3133073BC9630676D8BC63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =20 > > Avi had sent an email explaining how this is not same as regular WiFi > access. Please see the attachment for his email. > > =20 > > Neither Avi nor I was at the meeting to re-iterate these points. > Hopefully this explanation is sufficient. If not, let us know. > > I for one didn't get the difference between normal WiFi and WiMAX-Wifi-IWK. The email sounded like WiMAX is doing WiFi+additional things, i.e. a "profile" of WiFi. The argument in the meeting was: is the stuff that WiMAX-Wifi is doing conformant to IEEE 802.11? If yes, it *is* WiFi and there's a NAS-Port-Type allocation for it already. If it is *not* conforming to IEEE 802.11, then maybe it needs a new NAS-Port-Type. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig8C3133073BC9630676D8BC63 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ils0ACgkQ+jm90f8eFWYUfACcCwF1LcWIHyalS2DPODWPpgqN boEAoIJnqxkLGOBFvM4A2hxLqu2O45GW =NHmL -----END PGP SIGNATURE----- --------------enig8C3133073BC9630676D8BC63-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 10 Apr 2011 20:42:11 +0000 From: "Alper Yegin" To: "'Sanchez, Mauricio \(HP Networking\)'" , Subject: RE: Consensus poll for IANA #409959 NAS-Port-Type value request Date: Sun, 10 Apr 2011 23:41:12 +0300 Message-ID: <03b801cbf7bf$a4d24910$ee76db30$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_03B9_01CBF7D8.CA1F8110" Thread-Index: Acv2GxXYOSeCUwMVR9aWHRCiIJ9EjABo7Mig Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_03B9_01CBF7D8.CA1F8110 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03BA_01CBF7D8.CA1F8110" ------=_NextPart_001_03BA_01CBF7D8.CA1F8110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Avi had sent an email explaining how this is not same as regular WiFi access. Please see the attachment for his email. Neither Avi nor I was at the meeting to re-iterate these points. Hopefully this explanation is sufficient. If not, let us know. Alper From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, Mauricio (HP Networking) Sent: Friday, April 08, 2011 9:31 PM To: 'radiusext@ops.ietf.org' Subject: Consensus poll for IANA #409959 NAS-Port-Type value request During IETF 80 one of the agenda topics discussed was whether to approve a request received by IANA for allocation of additional NAS-port-type values relating to Wimax as described below Type of Assignment : Nas-Port-Type values as follows: TBD for WIMAX-3GPP-PRIF: WiMAX Pre-Release 8 IWK Function TBD for WIMAX-WIFI-IWK: WiMAX WIFI Interworking TBD for WIMAX-SFF: Signaling Forwarding Function for LTE/3GPP2. TBD for WIMAX-HA-LMA: WiMAX HA and or LMA function. TBD for WIMAX-DHCP : WIMAX DCHP service TBD for WIMAX- LBS : WiMAX location based service TBD for WIMAX-WVS : WiMAX voice service The snippet of meeting notes relating to this topic are show below: ---- --------------------------- Request for registration for NAS-port-type. Under 3575, falls under expert review. This request is for NAS-port-type relating to WiMax - Stefan comments that there's already type for WiFi so not sure why another one is needed, just one. - Klaas comments that agrees with Stefan's comments. - Nancy comments that looking at the current assignment is that there is only 1 allocation per mode. - Bernard takes the general comment of only allocating one as the response to take back to the request. Given consensus here, will verify that opinion in the reflector. ---- --------------------------- The sentiment in the room was clearly against approving this IANA request and at this time we would like to confirm this on the mailing list. Please respond to this email and state whether you are in favor or against approving this IANA request. Thanks, MS ------=_NextPart_001_03BA_01CBF7D8.CA1F8110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Avi had sent an email = explaining how this is not same as regular WiFi access. Please see the attachment = for his email.

 

Neither Avi nor I was = at the meeting to re-iterate these points. Hopefully this explanation is = sufficient. If not, let us know.

 

Alper

 

 

 

From:= = owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Sanchez, = Mauricio (HP Networking)
Sent: Friday, April 08, 2011 9:31 PM
To: 'radiusext@ops.ietf.org'
Subject: Consensus poll for IANA #409959 NAS-Port-Type value = request

 

During IETF 80 one of the agenda topics discussed = was whether to approve a request received by IANA for allocation of = additional NAS-port-type values relating to Wimax as described below =

 

Type of Assignment :
Nas-Port-Type values as follows:
TBD for WIMAX-3GPP-PRIF:  WiMAX Pre-Release 8 IWK Function
TBD for WIMAX-WIFI-IWK:  WiMAX   WIFI Interworking
TBD for WIMAX-SFF: Signaling Forwarding Function  for = LTE/3GPP2.
TBD for WIMAX-HA-LMA:  WiMAX HA and or = LMA   function.
TBD for WIMAX-DHCP : WIMAX DCHP service

TBD for WIMAX- LBS  : WiMAX location = based service
TBD for WIMAX-WVS : WiMAX  voice service

 

The snippet of meeting notes relating to this topic = are show below:

 

---- <meeting note snippet begin>---------------------------

 

Request for registration for NAS-port-type.  = Under 3575, falls under expert review.  This request is for NAS-port-type relating to WiMax

- Stefan comments that there’s already type = for WiFi so not sure why another one is needed, just one.

- Klaas comments that agrees with Stefan’s = comments.

- Nancy comments that looking at the current = assignment is that there is only 1 allocation per mode.

- Bernard takes the general comment of only = allocating one as the response to take back to the request.  Given consensus here, = will verify that opinion in the reflector.

 

---- <meeting note snippet end>---------------------------

 

The sentiment in the room was clearly against = approving this IANA request and at this time we would like to confirm this on the = mailing list.  

 

Please respond to this email and state whether you = are in favor or against approving this IANA request. 

 

Thanks,

MS

 

------=_NextPart_001_03BA_01CBF7D8.CA1F8110-- ------=_NextPart_000_03B9_01CBF7D8.CA1F8110 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: attachment Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by mx.perfora.net (node=mxus0) with ESMTP (Nemesis) id 0MRnhx-1PWinr3eK9-00T7qC for alper.yegin@yegin.org; Tue, 15 Mar 2011 13:39:39 -0400 Received: (qmail 27728 invoked from network); 15 Mar 2011 17:39:37 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-5.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2011 17:39:37 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 15 Mar 2011 13:39:36 -0400 Return-Path: From: "Avi Lior" To: Cc: , "Alper Yegin" Subject: [IANA #409959] Genreral Request for Assignements Date: Tue, 15 Mar 2011 20:39:35 +0300 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B4_01CBF7D8.CA078C40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvjN/PfETWqJsnhRbCJ3Q5584NJVA== Content-Language: en-us X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Originating-IP: [72.35.6.119] X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-5.tower-200.messagelabs.com!1300210776!92153259!1 X-StarScan-Version: 6.2.9; banners=-,-,- This is a multipart message in MIME format. ------=_NextPart_000_03B4_01CBF7D8.CA078C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Bernard, Thank you for the review of the NAS-Port-Type IANA request for assignment. In a previous email you were seeking answers to the following questions: Bernard wrote: Can someone answer the following questions? 1. What is different between WiMAX WiFi and normal IEEE 802.11? We already have a number of IEEE 802.11 NAS-Port-types allocated and have proposed additional data for this. 2. Why do DHCP and a location service need NAS-Port-Type values? 3. Why should we just allocate a generic WiMAX NAS-Port and let additional data be included in a WiMAX Forum VSA? The general answer to your question is as follows: For a given session, the WIMAX AAA Server interacts with many different WiMAX network elements and also non-WiMAX network elements. The approach taken by WiMAX is to have an explicit indication from the NAS as to the context of the RADIUS access-request. The NAS-Port-Type is viewed as the attribute to provide that information. WRT 1) the WiMAX AAA needs to be able to differentiate between a normal WiFi Access and a WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additional behaviours over and above the "normal" wifi AP. T WRT 2) Again, WiMAX AAA needs to differentiate between the request from both these entities because the AAA behaviour is different when request comes from a DHCP server vs., a Location Based Server. WRT 3) WiMAX would just be inventing our own NAS-Port-Type attribute. We thought the idea is that we reuse attributes when we can. Since there doesn't seem to be a lack of number space associated with NAS-Port-Type there doesn't seem to be a reason to invent our own attribute. -- Avi Lior --Bridgewater Systems ------=_NextPart_000_03B4_01CBF7D8.CA078C40 Content-Type: text/html; boundary="_000_C9A51C9711D20avibridgewatersystemscom_"; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 Hi = Bernard,

Thank you for the review of the = NAS-Port-Type IANA request for assignment.  In a previous email you = were seeking answers to the following questions:

Bernard wrote:

Can someone = answer the following questions?

1. What is = different between WiMAX WiFi and normal IEEE 802.11?  We already = have a number of IEEE 802.11 NAS-Port-types allocated and have proposed = additional data for this.

2. Why do DHCP and a location service = need NAS-Port-Type values? 

3. Why = should we just allocate a generic WiMAX NAS-Port and let additional data = be included in a WiMAX Forum VSA?

The general answer to your question = is as follows:

For a given session, the WIMAX AAA Server interacts with many = different WiMAX network elements and also non-WiMAX network elements. =  The approach taken by WiMAX is to have an explicit indication from = the NAS as to the context of the RADIUS access-request.  The = NAS-Port-Type is viewed as the attribute to provide that = information.

WRT 1) the WiMAX AAA needs to be able to = differentiate between a normal WiFi Access and a WiMAX NAS which is an a = WiFI-WiMAX IWK NAS which has additional behaviours over and above the = "normal" wifi AP.  T


WRT 2) Again, WiMAX AAA needs to = differentiate between the request from both these entities because the = AAA behaviour is different when request comes from  a DHCP server = vs., a Location Based Server.

WRT 3)  WiMAX would just be inventing = our own NAS-Port-Type attribute.  We thought the idea is that we = reuse attributes when we can. Since there doesn't seem to be a lack of = number space associated with NAS-Port-Type there doesn't seem to be a = reason to invent our own attribute.


-- Avi = Lior
--Bridgewater = Systems

------=_NextPart_000_03B4_01CBF7D8.CA078C40-- ------=_NextPart_000_03B9_01CBF7D8.CA1F8110-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 10 Apr 2011 19:22:05 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Sun, 10 Apr 2011 19:21:46 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #71: Section 2.3 and 3.3 Message-ID: <075.3754ce10466b7b5d17205d842dc5e86b@trac.tools.ietf.org> #71: Section 2.3 and 3.3 Comment(by bernard_aboba@…): Here is potential replacement text for Section 3.3: 3.3. Route-IPv6-Information This Attribute specifies a prefix (and corresponding route) for the user on the NAS, which is to be announced using the Route Information Option defined in "Default Router Preferences and More Specific Routes" [RFC4191] Section 2.3. It is used in the Access-Accept packet and can appear multiple times. It may also be used in the Access-Request packet as hint to the server. A summary of the Route-IPv6-Information attribute format is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA3 for Route-IPv6-Information Length Length in bytes. At least 4 and no larger than 20; typically 12 or less. Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The Prefix field is 0, 8, or 16 octets depending on Length. Prf (Route Preference) 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others, when multiple identical prefixes (for different routers) have been received. Resvd (Reserved) Two 3-bit unused fields. They MUST be initialized to zero. Route Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xffffffff) represents infinity. Prefix Variable-length field containing an IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 10 Apr 2011 19:18:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Sun, 10 Apr 2011 19:18:32 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #69: Section 1 Message-ID: <075.e85e9a1e9b07c1692899b187d5ca16c3@trac.tools.ietf.org> #69: Section 1 Comment(by bernard_aboba@…): Here is some revised text: This document specifies additional RADIUS attributes used to support configuration of DHCPv6 and/or ICMPv6 parameters on a per-user basis. The attributes, which complement those defined in [RFC3162] and [RFC4818], support the following: o Assignment of specific IPv6 addresses to hosts via DHCPv6. While [RFC3162] permits an IPv6 address to be specified via the combination of the Framed-Interface-Id and Framed-IPv6-Prefix attributes, this separation is more natural for use with IPv6CP than it is for use with DHCPv6, and the use of a single IPv6 address attribute makes for easier processing of accounting records. o Assignment of an IPv6 DNS server address, via DHCPv6 or [RFC5006]. o Configuration of more specific routes to be announced to the user via the Route Information Option defined in [RFC4191] Section 2.3. While the Framed-IPv6-Prefix Attribute defined in [RFC3162] Section 2.3 causes the route to be advertised in an RA, it cannot be used to configure more specific routes. While the Framed-IPv6-Route Attribute defined in [RFC3162] Section 2.5 causes the route to be configured on the NAS, and potentially announced via an IGP, depending on the value of Framed-Routing, it does not result in the route being announced in an RA. o The assignment of a named delegated prefix pool for use with "IPv6 Prefix Options for DHCPv6" [RFC3633]. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 10 Apr 2011 18:53:54 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_5d4939f6-cab7-48ec-8b52-aab0c8efdadc_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Route-IPv6-Information Attribute Date: Sun, 10 Apr 2011 11:53:41 -0700 MIME-Version: 1.0 --_5d4939f6-cab7-48ec-8b52-aab0c8efdadc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF-80 we discussed the differences between the Framed-IPv6-Prefix=2C F= ramed-IPv6-Route and Route-IPv6-Information attributes. The differences ap= pear to be as follows: Framed-IPv6-Prefix: Configures an IPv6 prefix (and route) for the user on = the NAS and results in the prefix being advertised in an RA from the NAS.=20 Framed-IPv6-Route: Configures additional routes on the NAS. These additio= nal routes may be advertised by an IGP=2C depending on the value of Framed-Routing.=20 Route-IPv6-Information: Configures additional routes on the NAS. These ad= ditional routes will be advertised within the RA via the Route Information = Option described in RFC 4191 Section 2.3.=20 In comparing RFC 4191 Section 2.3 with the format of the Route-IPv6-Informa= tion Attribute=2C there appear to be some differences in the information in= cluded. The Route-IPv6-Information Attribute does not include the Route Pr= eference or the Route Lifetime within the Route Information Option. Also t= he definition of the Prefix Length and Prefix appears to be different. Is = there a reason for this?=20 Assuming that it is desirable to utilize the same format for the Attribute = and the Option=2C potential replacement text for Section 3.3 would be as fo= llows: 3.3. Route-IPv6-Information This Attribute specifies a prefix (and corresponding route) for the user on the NAS=2C which is to be announced using the Route Information Option defined in "Default Router Preferences and More Specific Routes" [RFC4191] Section 2.3. It is used in the Access-Accept=20 packet and can appear multiple times. It may also be used in the Access-Request packet as hint to the server. A summary of the Route-IPv6-Information attribute format is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA3 for Route-IPv6-Information Length Length in bytes. At least 4 and no larger than 20=3B typically 12 or less. Prefix Length 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. The Prefix field is 0=2C 8=2C or 16 octets depending o= n Length. Prf (Route Preference) 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others=2C when multiple identical prefixes (for different routers) have been received.=20 Resvd (Reserved) Two 3-bit unused fields. They MUST be initialized to zero. Route Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xffffffff) represents infinity. Prefix Variable-length field containing an IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero. Does this make sense? = --_5d4939f6-cab7-48ec-8b52-aab0c8efdadc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At IETF-80 we discussed the differences between the Framed-IPv6-Prefix=2C F= ramed-IPv6-Route and Route-IPv6-Information attributes. =3B The differe= nces appear to be as follows:

Framed-IPv6-Prefix: =3B Configures= an IPv6 prefix (and route) for the user on the NAS and results in the pref= ix being advertised in an RA from the NAS.

Framed-IPv6-Route: = =3B Configures additional routes on the NAS. =3B These additional route= s may be advertised by an IGP=2C
depending on the value of Framed-Routin= g.

Route-IPv6-Information: =3B Configures additional routes on = the NAS. =3B These additional routes will be advertised within the RA v= ia the Route Information Option described in RFC 4191 Section 2.3.

= In comparing RFC 4191 Section 2.3 with the format of the Route-IPv6-Informa= tion Attribute=2C there appear to be some differences in the information in= cluded. =3B The Route-IPv6-Information Attribute does not include the R= oute Preference or the Route Lifetime within the Route Information Option.&= nbsp=3B Also the definition of the Prefix Length and Prefix appears to be d= ifferent. =3B Is there a reason for this?

Assuming that it is d= esirable to utilize the same format for the Attribute and the Option=2C pot= ential replacement text for Section 3.3 would be as follows:

3.3. Ro= ute-IPv6-Information

 =3B =3B This Attribute specifies a pre= fix (and corresponding route) for the
 =3B =3B user on the NAS= =2C which is to be announced using the Route Information
 =3B = =3B Option defined in "Default Router Preferences and More Specific
&nbs= p=3B =3B Routes" [RFC4191] Section 2.3. =3B =3B It is used in t= he Access-Accept
 =3B =3B packet and can appear multiple times.=  =3B It may also be
 =3B =3B used in the Access-Request pack= et as hint to the server.

 =3B =3B A summary of the Route-IP= v6-Information attribute format is shown
 =3B =3B below.

=  =3B =3B =3B =3B =3B 0 =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B 1 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B 2 =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B 3
 =3B =3B =3B =3B =3B&= nbsp=3B 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=  =3B =3B =3B =3B =3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =3B =3B =3B =3B =3B= | =3B =3B =3B =3B Type =3B =3B =3B =3B&nbs= p=3B | =3B =3B =3B Length =3B =3B =3B =3B | Pre= fix Length |Resvd|Prf|Resvd|
 =3B =3B =3B =3B =3B +-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 =3B=  =3B =3B =3B =3B | =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B Route = Lifetime =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B |
 =3B =3B&n= bsp=3B =3B =3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
 =3B =3B =3B =3B =3B | =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B Prefix (Variable Leng= th) =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B |
 =3B =3B =3B =3B =3B . =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B .
 =3B =3B =3B =3B =3B .=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B .
 =3B =3B = =3B =3B =3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+

 =3B =3B Type

 =3B =3B =3B&nbs= p=3B =3B TBA3 for Route-IPv6-Information

 =3B =3B Length=

 =3B =3B =3B =3B =3B Length in bytes. =3B A= t least 4 and no larger than 20=3B typically 12
 =3B =3B =3B=  =3B =3B or less.

 =3B =3B Prefix Length
 =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B 8-bit unsigned integer. =3B The number of= leading bits in
 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B the Prefix that= are valid. =3B The value ranges from 0 to
 =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B 128. =3B The Prefix field is 0=2C 8=2C or 16 octets depend= ing on
 =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B Length.

 =3B&nbs= p=3B Prf (Route Preference)
 =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B 2-bit = signed integer. =3B The Route Preference indicates
 =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B whether to prefer the router associated with this pref= ix
 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B over others=2C when multiple id= entical prefixes (for
 =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B different ro= uters) have been received.

 =3B =3B Resvd (Reserved)
&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B Two 3-bit unused fields. =3B They M= UST be initialized to
 =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B zero.
 =3B =3B Route Lifetime
 =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= 32-bit unsigned integer. =3B The length of time in seconds
 =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B (relative to the time the packet is sent) tha= t the prefix
 =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B is valid for route de= termination. =3B A value of all one
 =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B bits (0xffffffff) represents infinity.

 =3B =3B Prefix=  =3B =3B =3B =3B =3B Variable-length field containing a= n IP address or a
 =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B prefix of an IP= address. =3B The Prefix Length field
 =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B contains the number of valid leading bits in the prefix.
 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B The bits in the prefix after the prefix le= ngth (if any)
 =3B =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B are reserved and MUS= T be initialized to zero.


Does this make sense?



= = --_5d4939f6-cab7-48ec-8b52-aab0c8efdadc_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 10 Apr 2011 18:50:41 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Sun, 10 Apr 2011 18:49:40 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #71: Section 2.3 and 3.3 Message-ID: <075.2072b49294f08276ddbd367ff589ecd9@trac.tools.ietf.org> #71: Section 2.3 and 3.3 Comment(by bernard_aboba@…): We discussed the distinction between the various attributes at IETF-80: Framed-IPv6-Prefix: Configures an IPv6 prefix (and route) for the user on the NAS and results in the prefix being advertised in an RA from the NAS. Framed-IPv6-Route: Configures additional routes on the NAS. These additional routes may be advertised by an IGP, depending on the value of Framed-Routing. Route-IPv6-Information: Configures additional routes on the NAS. These additional routes will be advertised within the RA via the Route Information Option described in RFC 4191 Section 2.3. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 09 Apr 2011 21:08:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 09 Apr 2011 21:07:57 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #92: End-to-end versus hop-by-hop confidentiality Message-ID: <066.c8181cac1a08fae95845dd7c3e9fa8b7@trac.tools.ietf.org> #92: End-to-end versus hop-by-hop confidentiality The document currently does not make it clear what the requirements are for end-to-end confidentiality. The proposal is to change the text on "Limit Key Scope" in Section 4.2 to the following: Limit key scope It is RECOMMENDED that solutions enable a NAS and RADIUS server to exchange confidential information such as keying material without disclosure to third parties. In order to accomplish this, it is RECOMMENDED that a RADIUS crypto-agility solution be compatible with NAI-based Dynamic Peer Discovery [RADYN] as well as that it support the use of public key credentials for authentication between the NAS and RADIUS server. For compatibility with existing operations, RADIUS crypto-agility solutions SHOULD also support pre-shared key credentials. However, support for end-to-end confidentiality of attributes or direct communications between the NAS and RADIUS server is not required when pre-shared key credentials are used. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 09 Apr 2011 20:57:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 09 Apr 2011 20:56:02 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #89: Key Wrap and Password Hiding Requirements Message-ID: <075.bba5fde9390a211500f0aa6a61ce6096@trac.tools.ietf.org> #89: Key Wrap and Password Hiding Requirements Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed Resolution: Change the following text in Section 4.2: It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. This includes providing support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption. To: It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption. Solutions providing for encryption of entire RADIUS packets need not also provide support for encryption of individual RADIUS attributes. Solutions providing for encryption of individual RADIUS attributes are REQUIRED to provide support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 08 Apr 2011 18:35:11 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Fri, 8 Apr 2011 18:30:56 +0000 Subject: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Topic: Consensus poll for IANA #409959 NAS-Port-Type value request Thread-Index: Acv2GxXYOSeCUwMVR9aWHRCiIJ9EjA== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9GVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9GVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During IETF 80 one of the agenda topics discussed was whether to approve a = request received by IANA for allocation of additional NAS-port-type values = relating to Wimax as described below Type of Assignment : Nas-Port-Type values as follows: TBD for WIMAX-3GPP-PRIF: WiMAX Pre-Release 8 IWK Function TBD for WIMAX-WIFI-IWK: WiMAX WIFI Interworking TBD for WIMAX-SFF: Signaling Forwarding Function for LTE/3GPP2. TBD for WIMAX-HA-LMA: WiMAX HA and or LMA function. TBD for WIMAX-DHCP : WIMAX DCHP service TBD for WIMAX- LBS : WiMAX location based service TBD for WIMAX-WVS : WiMAX voice service The snippet of meeting notes relating to this topic are show below: ---- --------------------------- Request for registration for NAS-port-type. Under 3575, falls under expert= review. This request is for NAS-port-type relating to WiMax - Stefan comments that there's already type for WiFi so not sure why anothe= r one is needed, just one. - Klaas comments that agrees with Stefan's comments. - Nancy comments that looking at the current assignment is that there is on= ly 1 allocation per mode. - Bernard takes the general comment of only allocating one as the response = to take back to the request. Given consensus here, will verify that opinio= n in the reflector. ---- --------------------------- The sentiment in the room was clearly against approving this IANA request a= nd at this time we would like to confirm this on the mailing list. Please respond to this email and state whether you are in favor or against = approving this IANA request. Thanks, MS --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9GVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

During IETF 80 o= ne of the agenda topics discussed was whether to approve a request received= by IANA for allocation of additional NAS-port-type values relating to Wima= x as described below

 <= /p>

Type of Assignment :
Nas-Port-Type values as fol= lows:
TBD for WIMAX-3GPP-PRIF:  WiMAX Pre-Release 8 IWK Functi= on
TBD for WIMAX-WIFI-IWK:  WiMAX   WIFI Interworking
= TBD for WIMAX-SFF: Signaling Forwarding Function  for LTE/3GPP2.<= br>TBD for WIMAX-HA-LMA:  WiMAX HA and or LMA   functio= n.
TBD for WIMAX-DHCP : WIMAX DCHP service

TBD for WIMAX- LBS  : WiMAX location based service
TBD f= or WIMAX-WVS : WiMAX  voice service

 

The snippet of meeting note= s relating to this topic are show below:

 

---- <meeting note snippet be= gin>---------------------------

=  

Request for registration for NAS-port= -type.  Under 3575, falls under expert review.  This request is f= or NAS-port-type relating to WiMax

- Ste= fan comments that there’s already type for WiFi so not sure why anoth= er one is needed, just one.

- Klaas comm= ents that agrees with Stefan’s comments.

- Nancy comments that looking at the current assignment is that ther= e is only 1 allocation per mode.

- Berna= rd takes the general comment of only allocating one as the response to take= back to the request.  Given consensus here, will verify that opinion = in the reflector.

 

<= p class=3DMsoNormal>---- <meeting note snippet end>------------------= ---------

 

The sentiment in the room was clearly against approving this I= ANA request and at this time we would like to confirm this on the mailing l= ist.  

 

Please respond to this email and state whether you are in fav= or or against approving this IANA request. 

 

Thanks,

<= p class=3DMsoNormal>MS

 

= --_000_9BC2F7926B33FE4AB10D69891D58FC1C5C6F2F2EB9GVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 04 Apr 2011 07:57:43 +0000 Message-ID: <4D9979BB.7040803@restena.lu> Date: Mon, 04 Apr 2011 09:56:43 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ignacio Goyret CC: Mark Smith , Alan DeKok , "radiusext@ops.ietf.org" Subject: Re: 64 bit data types Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig04A48BB437536CFD7FABA983" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig04A48BB437536CFD7FABA983 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> I think there would be a very useful benefit in 64 bit data types. >> .... >> 64 bit counters would mean one less thing to handle in accounting >> code, and one less thing to have to worry about testing. > +1 Good! Alan suggested the extended-attributes draft to handle this. I second that, since a new datatype is a more architectural change, and deserves more visibility, than the simple things "fancyaccounting" tries to achieve. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig04A48BB437536CFD7FABA983 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Zeb4ACgkQ+jm90f8eFWb67wCeMn5JKyGWkRAZhRRcmwdIeJse MD0AnRu4IDPaaz2Z4uovJXwuhJAZvkYf =sZY/ -----END PGP SIGNATURE----- --------------enig04A48BB437536CFD7FABA983-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 03 Apr 2011 12:43:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Call for Nominees - RADEXT WG co-chair Date: Sun, 3 Apr 2011 14:41:01 +0200 Message-ID: Thread-Topic: Call for Nominees - RADEXT WG co-chair Thread-Index: Acvx/GN3FIYVbeN7SV+nEJcHE56NoQ== From: "Romascanu, Dan (Dan)" To: "radext mailing list" Hi,=20 As announced in the WG meeting in Prague, following his nomination as Chair of the IAB Bernard Aboba will need to release some of his current positions among which the position of co-chair of the RADEXT WG.=20 Thanks to Bernard for his exceptional contributions as WG chair.=20 I am opening the process of selection of a new co-chair to lead the working group together with Mauricio who is continuing in his position. If you feel qualified and are willing to serve as RADEXT WG co-chair please send me a mail on this respect before Tuesday 4/12.=20 Thanks and Regards, Dan=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 02 Apr 2011 06:33:58 +0000 Message-ID: <4D96C310.4040200@deployingradius.com> Date: Sat, 02 Apr 2011 08:32:48 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon CC: "'radiusext@ops.ietf.org'" Subject: Re: 6rd attribute compromise? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Peter Deacon wrote: > As a compromise any thoughts about defining stand-ins for what are > essentially TLVs to remove external dependencies? It's a good idea, I think. > Upside future implementations supporting TLVs *may* be able to more > broadly support the 6rd configuration attribute. > > Downside at least 7 more bytes for this attribute, more work to manage > additional static fields. I'm not concerned about 7 bytes, and TLVs should make it easier to add more fields. The extended attrs document says that TLV formats should not be used for "normal" attributes. That's only because it may be useful to group all of the new features together. That can be changed. An alternative approach would be to publish a "new data types" RFC, containing just TLV and 64-bit integer data types. It should be simple enough that publication should be quick. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 01 Apr 2011 18:19:38 +0000 Date: Fri, 1 Apr 2011 11:18:15 -0700 (Pacific Daylight Time) From: Peter Deacon To: "'radiusext@ops.ietf.org'" Subject: 6rd attribute compromise? Message-ID: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="763195077-18522-1301676194=:2688" Content-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --763195077-18522-1301676194=:2688 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 1 Apr 2011, Sanchez, Mauricio (HP Networking) wrote: > 3. RADIUS Attributes for 6rd, Sheng Jiang > http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib > - Bernard asks how many IPv4 address can be included? And how do you > know how many are there? Response: can know counted based on the > length. Bernard comments that AVP are typically fixed length, this > request is a dynamic length. Other question is can we have many of these > attributes? > - Nancy asks on clarify on fixed length vs. dynamic length. Bernard > clarifies that there are two ways to do this, but one issue is how to > map the 6rd prefix. > - Alan says can do this through extended attributes. > - Bernard comments that it¢s a question of timing. > - Nancy says that would build a dependency on the extended attributes. > - Alan and Bernard agrees. As a compromise any thoughts about defining stand-ins for what are essentially TLVs to remove external dependencies? Upside future implementations supporting TLVs *may* be able to more broadly support the 6rd configuration attribute. Downside at least 7 more bytes for this attribute, more work to manage additional static fields. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SubType (1) | SubLen (3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4MaskLen | SubType (2) | SubLen (20) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6rdPrefixLen | 6rdPrefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubType (3) | SubLen (6) |6rdBRIPv4Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ regards, Peter --763195077-18522-1301676194=:2688-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 01 Apr 2011 12:04:34 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "'radiusext@ops.ietf.org'" Date: Fri, 1 Apr 2011 12:00:39 +0000 Subject: Minutes of RADEXT meeting at IETF 80 Thread-Topic: Minutes of RADEXT meeting at IETF 80 Thread-Index: AcvwZBFzWZr+6dDaQNKDVloUujyc8g== Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5B555A194E@GVW0671EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9BC2F7926B33FE4AB10D69891D58FC1C5B555A194EGVW0671EXCame_" MIME-Version: 1.0 --_000_9BC2F7926B33FE4AB10D69891D58FC1C5B555A194EGVW0671EXCame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Meeting minutes from this week's meeting below. Thanks go to Nancy for the= note taking. Note corrections are welcome. -Mauricio RADEXT WG Minutes IETF 80 Prague, Czech Republic Wednesday March 30, 2011 Meeting started 9:02AM and ended 11:27AM CEST. Approximately 17 individual= s in meeting. Chairs: Bernard Aboba Mauricio Sanchez 1. Preliminaries Audio/Video & Remote Presentation Debugging Note Well Note Takers - Note volunteer Nancy Cam-Winget Jabber scribe - Stefan W. jabber scribe - Dan Romanascu asks for the floor for 1 min: Intervenes to announce that B= ernard is now IAB Chair. As a result, he needs to release some responsibil= ity. Dan recognizes his work in radext and thanks him for his contribution= s. So, now as a result, there is an open process to find a co-chair to wor= k with Mauricio. Bernard will help while transition occurs. If interested= or have questions, can approach Dan or Bernard to learn about what the job= entails. Agenda bash - review of IPv6, then security work items and wrapup. There was a request= to move one of the presos due to meeting conflicts. Document Status -2 publications: status-server and design guidelines -1 in RFC queue: radius over TCP -3 completed WGLC * New tunnel types values: Pending IANA resolution * IPv6 RADIUS attributes: open issues * crypto-agility: open issues 2. IANA issues A. How to allocate tunnel params? In RFC 3575 (RFC2868 conflicts as 3575= assigns based on expert review but didn't update 2868). Omission of RFC 2= 868 could be an errata; this is basically a request for metadata. - Asks Dan for comment: was looking for input from the working group before= proceeding. - Alan thought it was an errata. - Stefan states no opinion. - Klaas also states no opinion. - Nancy asks for further understanding. Bernard clarifies: RFC 2868 states = "standards action" and 3575 is more lenient in saying just expert review. - Now Dan remembers: when there's conflicts such as this, 2 solutions: take= the stricter or take the latest. But if it's the latest, then it needs to = be clearer. Believes in this case, explicit clarification is justified sin= ce 3575 is more recent and the request is justified. But need IESG perspec= tive review by WG. - Bernard suggests to get a sense of this group and then take it to the mai= lgroup. Asks: proposal is to accept and verify the errata and update 3575 = to include 2868. In favor: 10, non oppose. Given consensus, will take to = the mail list. B. Request for registration for NAS-port-type. Under 3575, falls under = expert review. This request is for NAS-port-type relating to WiMax - Stefan comments that there's already type for WiFi so not sure why anothe= r one is needed, just one. - Klaas comments that agrees with Stefan's comments. - Nancy comments that looking at the current assignment is that there is on= ly 1 allocation per mode. - Bernard takes the general comment of only allocating one as the response = to take back to the request. Given consensus here, will verify that opinio= n in the reflector. 3. RADIUS Attributes for 6rd, Sheng Jiang http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib - 6rd used to provide IPv6 connectivity svcs thru IPv4....there's a working= group draft. In some scenarios, the access gateway acts as access gateway= of users. So user config info can be managed by AAA servers (between AAA = and BNG, RADIUS is used to carry the info). New attributes are needed to p= ropagate this info. - Proposal to add a IPv6-6rd-config attribute. A draft was presented by th= e Softwire WG and accepted as a working group iten in the Beijing meeting. = Also added request to RADEXT WG maillist. Received good comments to name = the attribute, fix the error on counting length (acknowledges Alan DeKok ).= The Softwire WG is ready for last call after this meeting, so if there's = more feedback by radext then we can move forward. - Bernard asks how many IPv4 address can be included? And how do you know = how many are there? Response: can know counted based on the length. Berna= rd comments that AVP are typically fixed length, this request is a dynamic = length. Other question is can we have many of these attributes? - Nancy asks on clarify on fixed length vs. dynamic length. Bernard clarif= ies that there are two ways to do this, but one issue is how to map the 6rd= prefix. - Alan says can do this through extended attributes. - Bernard comments that it's a question of timing. - Nancy says that would build a dependency on the extended attributes. - Alan and Bernard agrees. - Bernard notes that we can ask for a review again. 4. RADIUS Issues in IPv6 Deployments, Jacni Qin http://tools.ietf.org/html/draft-hu-v6ops-radius-issues-ipv6 Thanks Bernard for helping find the right WG to bring the issues - Issues encountered: 1st is identifying users on diff protocols. That is, = hard to characterize after user authN whether the authZ for v4 or v6 - 2nd issue: network or host on customer premises - 3rd issue: protocol specific accounting - Possible solution: * Use vendor specific attributes to solve all problems but lacks interop. * Can have special implementations of NAS to addres issue 1 and 2. Set seve= ral domains on NAS like "v4, v6 or dual stack" with "framed host, or home n= etwork" then require users to attach the addition info (like @domain) when = sending the request. * Asks the WG for advice. Would like to define new attributes to solave al= l issues....for the 3rd issue, to address "framed" services like 'acct-fram= ed-ipv4-input/output-*' * Asks if it can be adopted as an informational document? And if so, what's= the right approach? * Bernard discusses, orginal 3162 only handles a specific set (PPP access) = of IPv6, then added prefix delegation. There's another draft to deal with o= ther scenarios (like dsl and wlan)....and expanding (like 6rd) and expandin= g attributes as IPv6 deployments come to light. Part of the problem is 3162= only addresses one scenario....so are the existing definitions used to fit= the new scenarios? Suggests that we hold on as we will be discussing issu= e #2 later in this session. But for issue #1 asks Alan on the accounting i= ssue, with adding IPv6. Alan comments that the attributes are global, there= was a thread before; in 2866 don't have anything to do with IPv4 other tha= n getting an IPv4 address in the packet. So, what do you do when user has m= ultiple IP addresses? Given specs are silent, there are diff implementation= s. Bernard agrees.acct info is for all of the user's traffic but "what that= means" is based on the implementation. * Jouni Kohren comments: in mobile network, there's a similar situation. Th= ey use what is done today, but there are also other attributes to tell the = service type based on that authZ happens. At least for mobile networks its= similar and we have used what's there using vendor AVPs. * Bernard asks: how do you handle the accounting packets? Jouni responds: = based on time.but it's really a don't care if its v4 or v6. * Bernard suggests another way to do the accounting if want to separate v4 = or v6 but Jacni says its too tricky. * Jacni suggests that perhaps we allocate one new attribute for "framed" se= rvice? * Stefan wonders whether that would lead? As RADIUS doesn't look at distinc= tions (e.g no wired vs wireless), and this is doing it at the IP layers and= concerned that it may require too many new attributes * Jacni suggests can we just do the "framed" services? * Alan also expresses similar concerns to Stefan's comments. There's anoth= er scenario that uses multiple sessionID to track the multiple flows as opp= osed to allocating new attributes * Bernard understands multi-session id, but how to distinguish v4 vs v6? * Alan says session ID would also have the ipv4 addressing and correlate th= e multi-session ID to correlate the 2 sessions (1 being v4 and 2nd v6). * Leaf (Huawei) comments on technical report that is also looking at the tr= acking for the same session that has 2 traffic flows. The access server has= separate queues one for each v4 vs. v6....that means the access server sho= uld have the ability of providing the distinct information to report to the= AAA server and allow for different accounting policies. * Bernard: question to the floor was whether we should take this as a WG it= em? So, should issue 3 be a WG to solve this problem? * Leaf comments that question is whether we can take this informational? J= acni says its OK * Bernard wants to take the question: should we work on issue #3? 2 in fav= or, none against. Alan has no opinion * Stefan comments that what could be done is to specify it in a general way= so that detailed reports could be sent (against doing it just for v4 and v= 6 attributes). * Bernard thinks there's some interest.so we can take it on in the mail lis= t and figure out how to move forward. * Jacni comments that understands Stefan's concern but it is a high priorit= y item to them. * Bernard understands that we have a short timeframe especifally for v6. * Stefan suggests that a VSA can be used until a proper solution is in plac= e. * Jouni suggests to use VSA too. * Bernard closes by stating it will go to the mail list. 5.RADIUS Attributes for Dual Stack Access, L. Yeh http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access - Notes that draft is updated to -02, idea is roughly the same - This proposal helps address Jacni's issue but also questions whether othe= r attributes beyond the traffic count are needed. - Suggests there's another deployment scenario whereby you want to allow th= e operator (e.g. AAA server) for the type of user (e.g. dual stack, v4 only= , v6 only). - Proposes a list of User-Type values for handling service distinctions. - Bernard thanks for the comprehensive list. Notes another distinction of = how the routing goes from the nas to the cpe. There's also the framed-ipv6= route proposed which is what the nas advertises to the cpe. - Leaf notes that it's not about the route, this is about the accounting. - Asks if IPoE needs another set of codes? And similarly adding attributes = on the NAS-Port-Type or Framed-Protocol (with IPoE). - Mentions traffic statistic attribute values may be needed as well and pro= poses a new set for the use of dual stack. - Closes on whether these should be taken on as a WG item. - Stefan comments regarding the accounting express concern on the prolifera= tion of the different attributes. - Leaf states that the accounting is for per user. - Bernard asks if further comments? Notes that we agreed to look at statis= tics, but on the user-types don't need an explicit type as there's a way to= distinguish today, we may need to have means to distinguish NAS types. But= am not sure that we want another draft that discusses existing things alre= ady, so another one can cause further confusion. - Leaf counters that we need to solve current issues as operators need to c= hange the type of use (user-type), so we need AAA server to tell access ser= ver the user-type. - Bernard comments that there should already be a mechanism to help do that= . - Nancy asks is it just using the current attributes to distinguish the us= er type - Leaf wants new attributes to tell what kind of user it is. - Stefan points that current inspection of the current attributes already a= ssigned, then one can uniquely define the user type. - Bernard comments that the attributes today are already used to assign the= service. - Leaf comments that the NAS only has the pool names, want the AAA server t= o just tell the NAS the user type - Bernard is confused on what attributes are needed. - Stefan understands that AAA server doesn't give out the pool, just indica= tion to NAS a prefix, it doesn't have the framed attributes. - Bernard clarifies that server doesn't have the pool....and the pool name = should already map between NAS and AAA server. Suggests that we should bri= ng it to the list as we agreed to work on the accounting part, but we need = to better understand on what is missing to require the user type. 6. RADIUS Attributes for IPv6 Access Networks, W. Dec http://tools.ietf.org/html/draft-ietf-radext-ipv6-access - Bernard notes that we need a bit or work to resolve Wojciech's issue. Sl= ides are present, so Bernard reviews them: - Bernard describes problem: 3162 defines framed-ipv6-route, in 2865 also h= as framed-route (for ipv4) and framed-routing to describe options for how I= GP should behave. 3162 doesn't define the *-routing. - There doesn't seem to have an implication that IGP has been enabled...316= 2 defines route-ipv6-information attributes. Request is to clarify differe= nce between framed-ipv6-route and route-ipv6-information attribute. - Bernard asks if there are implementations of this so we can understand wh= at is actually done today? - Leaf asks which RFC? Bernard notes its 3162 that defines framed-ipv6-rout= e - This is the only issue holding up the RFC, so Bernard wants to gets this = resolved so that we can move forward without causing interop problems. - Bernard solicits input.none is provided - Jouni mentions that they've implemented IPv6 but ignore these attributes.= Bernard asks what info is provided to the RA? They do use the framed-ipv6= -prefix to the gateway....Bernard agrees that it would make sense. - RFC4191 is more specific routes draft.Bernard asks Jouni if they implemen= t today? Answer: no - Leaf comments 3162 has a different format for the route-ipv6-information.= The first only has a text string, the purpose may be the same, but the for= mats are different. So, the new draft could specify the prefix. - Bernard would like to claim that framed-ipv6-route has the same goals as = framed-route. The new attribute is for the more specific route while the ot= her is for IGP. Will bring this to the list to get consensus. 7. Crypto-Agility Requirements for RADIUS, Bernard Aboba http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements - Document to capture requirements and requests for review in TRAC to close= on this asap - Open issue 89: keywrap and password hiding requirements - If RADIUS is protected as a whole, is keywrap needed? - Stefan: is this an end to end keywrap vs. proxy? - Bernard believes it is hop by hop. - Stefan: if its end to end then there may be more benefit than if its just= hop by hop. - Bernard: confidentiality was not a requirement, so its possible that not = the whole packet is encrypted, so keywrap would be needed. So, we would wa= nt to keep this and clarify it in the doc. - Dan asks if there's a discussion on keywrap in future work? Since there's= Glen's draft as informational that perhaps we should move to standards spa= ce? Bernard comments that its in the queue so it's there. - Bernard suggests that we can do the writeup to state that if RADIUS is pr= otected, then keywrap is not needed; but if there's no protection then keyw= rap can be used. - Dan states that it makes sense, but need communication to the IESG that t= his is the resolution - Issue 90: process for publication and selection - Proposal is to define process through experimental drafts to define the m= echanisms that can be used. - With these 2 resolved, then it can go to final WGLC. 8. RADIUS over TLS, Stefan Winter http://tools.ietf.org/html/draft-ietf-radext-radsec - New draft submitted to address open issues except for "client id" - Everything goes thru one port - Auth server, acct server and dynauth server are separate entities - Client ID is hard as different modes need different treatment: PSK vs X.5= 09 fingerprint vs. X.509 proper (e.g. full chain, OCSP verification) - In RADIUS/UDP, client id =3D authZ used to exchange packets - For RADIUS/TLS-PSK: there can be more than 1 NAS talking - Biggest diff where client id !=3D authZ because the X.509 clients are uni= que identified by the issuer/serial number. So, can have authZ based on cli= ent types.can have that info in the cert data (policyOID) or out-certificat= e (query to some directory) - Bernard comments that it would be useful to communicate an error to deter= mine unauthorized certificate. Stefan: in this case, the connection would = just close. Bernard suggests that TLS error messages could also be used. = Stefan comments that he can look into it - Consequence to the spec: * Stack needs to expose ID criteria to admin: issuer/serial number * Need to add text/guidelines for AuthZ - Bernard suggests looking at "tls server id check" from Peter St Andre as = it relates to the dynamic discovery draft for how to delegate a server to a= domain and verify the trust. Also talks about other attributes that should= be looked at - Stefan would like to keep it simple by, say, looking at serial number onl= y - Dan speaking as contributor: there are many places in IETF discussing ide= ntities or places that can be looked at to get identity information. Don't= know if and how whether the problem can be solved consistently given that = there's no single model.but would like to point out that there are other pl= aces in IETF that also have this problem and may have ideas to use - Stefan notes that this document is still experimental and would like to l= ook at how industry currently looks and uses certificates - Given that there are more than 1 NAS as a potential, there's the question= of how a client ID can be used. 9. Dynamic Peer Discovery, Stefan Winter http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery - No new revision since last draft - Given that there are 3 separate entities, 3 labels are needed for auth, a= cct and dynauth - Could look like: S-NAPTRs: radius.tls, radacct.tls, raddynauth.tls - As a result can now generate a new draft - Jouni notes that there is a similar draft in DIAMETER that is going to IE= SG. Is this draft aligned with the one in DIAMETER? - Stefan notes that we are limited to 3. - Jouni notes that since there's nothing official in diameter, will there b= e 2 different or can we keep them the same? - Stefan notes that they are slightly different. Though radius could just u= se "aaa" with no extension 10. RADIUS over DTLS, Alan DeKok http://tools.ietf.org/html/draft-ietf-radext-dtls - No real changes since last IETF.current draft may be expired so need to u= pdate it - Open issues: need to resync with RTLS draft, double check consistency. Po= rt reuse issues, want review from Stig Venaas regarding the radsecproxy - There are 3 implementations radsecproxy, jradius, freeradius - Main dependency is the rtls sync - Stefan notes that the port number had been resolved to only use 1 port. A= lan agrees, just notes that the draft needs to be updated to reflect the ne= w outcome 11. RADIUS Protocol Extensions, Alan DeKok http://tools.ietf.org/html/draft-ietf-radext-radius-extensions - Almost same presentation as IETF 79.this has been discussed for many year= s - Review of current proposal: change 1 byte; take 1 byte from value to exte= nd type. Description of the new format to allow for 1.5K new attributes, al= low grouping via TLS, standard way to having "long" attrs and new means for= allowing vendors to have long VSA - Bernard notes that this kind of issue has arisen for a while now and the = hope that this one is more palatable to push forward. Need to bring it to = people who want it. - Stefan notes that when working on accounting and such those would be a go= od candidate for grouping them per this proposal. - Bernard notes that this may be good incentive to get the ones requesting = for new attributes to use this new way. - Mauricio comments that if we want people to use this, we need to wrap thi= s one up first so that we can then get the proposals for new attribute allo= cation to use this new format. - Bernard states that there were some that still did not want to use this..= .would be better if they would sign up willingly - Alan suggests that any new specs coming out, would be inclined to push th= em hard to use this - About 7 people have read the draft - Dan comments that it is useful, but at this point can not make it a shows= topper on other proposals until this document has been ratified. 12. Discussion and Wrap-up - Due to several topics running over, there was no time left to review next= steps. Chairs commented that several action items had been identified and= would be driven from the meeting notes. --_000_9BC2F7926B33FE4AB10D69891D58FC1C5B555A194EGVW0671EXCame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Meeting minute= s from this week’s meeting below.  Thanks go to Nancy for the no= te taking. 

Note corrections are welcome.

-Mauricio

 

 

 

RADEXT WG Minutes=

IETF 80

Prague, Czech Republic

Wednesday Ma= rch 30, 2011

Meeting started 9:02AM and = ended 11:27AM CEST.  Approximately 17 individuals in meeting.

 

Chair= s:  Bernard Aboba <bernard_aboba@hotmail.com>

       &n= bsp;        Mauricio Sanchez <ma= uricio.sanchez@hp.com>

 

1. Preliminari= es

Audio/Video & Remote Presentatio= n Debugging

Note Well

Note Takers

- Note volu= nteer Nancy Cam-Winget

Jabber scribe

- Stefan W. jabber scribe

 

- Dan Romanasc= u asks for the floor for 1 min: Intervenes to announce that Bernard is now = IAB Chair.  As a result, he needs to release some responsibility. = ; Dan recognizes his work in radext and thanks him for his contributions.&n= bsp; So, now as a result, there is an open process to find a co-chair to wo= rk with Mauricio.  Bernard will help while transition occurs.  If= interested or have questions, can approach Dan or Bernard to learn about w= hat the job entails.

 

Agenda bash

- rev= iew of IPv6, then security work items and wrapup.  There was a request= to move one of the presos due to meeting conflicts.

 

Document Status=

-2 publications: status-server and design gu= idelines

-1 in RFC queue: radius over TC= P

-3 completed WGLC

* New tunnel types values: Pending IANA resolution

* IPv6 RADIUS attributes: open issues<= /p>

* crypto-agility: open issues

 

2. IANA issues=

A.    How to allocate tunnel = params? In RFC 3575 (RFC2868 conflicts as 3575 assigns based on expert revi= ew but didn’t update 2868).  Omission of RFC 2868 could be an er= rata; this is basically a request for metadata. 

- Asks Dan for comment: was looking for input from the worki= ng group before proceeding. 

- Ala= n thought it was an errata.

- Stefan sta= tes no opinion.

- Klaas also states no o= pinion.

- Nancy asks for further underst= anding. Bernard clarifies: RFC 2868 states “standards action” a= nd 3575 is more lenient  in saying just expert review.

=

- Now Dan remembers: when there’s conflicts such= as this, 2 solutions: take the stricter or take the latest. But if it̵= 7;s the latest, then it needs to be clearer.  Believes in this case, e= xplicit clarification is justified since 3575 is more recent and the reques= t is justified.  But need IESG perspective review by WG.

- Bernard suggests to get a sense of this group and t= hen take it to the mailgroup.  Asks: proposal is to accept and verify = the errata and update 3575 to include 2868.  In favor: 10, non oppose.=   Given consensus, will take to the mail list.

 

B.   = Request for registration for NAS-port-type.  Under 3575, falls under = expert review.  This request is for NAS-port-type relating to WiMax

- Stefan comments that there’s alrea= dy type for WiFi so not sure why another one is needed, just one.

- Klaas comments that agrees with Stefan’s = comments.

- Nancy comments that looking = at the current assignment is that there is only 1 allocation per mode.=

- Bernard takes the general comment of only = allocating one as the response to take back to the request.  Given con= sensus here, will verify that opinion in the reflector.

 

 =

3. RADIUS Attributes for 6rd, Sheng Jiang

http://tools.ietf.org/html/draft-ietf-softwire-= 6rd-radius-attrib

- 6rd used to provide = IPv6 connectivity svcs thru IPv4….there’s a working group draft= .  In some scenarios, the access gateway acts as access gateway of use= rs.  So user config info can be managed by AAA servers (between AAA an= d BNG, RADIUS is used to carry the info).  New attributes are needed t= o propagate this info.

- Proposal to add= a IPv6-6rd-config attribute.  A draft was presented by the Softwire W= G and accepted as a working group iten in the Beijing meeting.  Also a= dded request to RADEXT WG maillist.  Received good comments to name th= e attribute, fix the error on counting length (acknowledges Alan DeKok ).&n= bsp; The Softwire WG is ready for last call after this meeting, so if there= ’s more feedback by radext then we can move forward.

- Bernard asks how many IPv4 address can be included?&nb= sp; And how do you know how many are there?  Response: can know counte= d based on the length.  Bernard comments that AVP are typically fixed = length, this request is a dynamic length.  Other question is can we ha= ve many of these attributes?

- Nancy ask= s on clarify on fixed length vs. dynamic length.  Bernard clarifies th= at there are two ways to do this, but one issue is how to map the 6rd prefi= x.

- Alan says can do this through exten= ded attributes.

- Bernard comments that = it’s a question of timing. 

= - Nancy says that would build a dependency on the extended attributes.

- Alan and Bernard agrees.

- Bernard notes that we can ask for a review again.=

 

4.= RADIUS Issues in IPv6 Deployments, Jacni Qin

http://tools.ietf.org/html/draft-hu-v6ops-radius-issues-ipv6

Thanks Bernard for helping find the right WG to= bring the issues

- Issues encountered: = 1st is identifying users on diff protocols. That is, hard to characterize a= fter user authN whether the authZ for v4 or v6

- 2nd issue: network or host on customer premises

- 3rd issue: protocol specific accounting

- Possible solution:

= * Use vendor specific attributes to solve all problems but lacks interop.

* Can have special implementations of NAS= to addres issue 1 and 2. Set several domains on NAS like “v4, v6 or = dual stack” with “framed host, or home network” then requ= ire users to attach the addition info (like @domain) when sending the reque= st.

* Asks the WG for advice.  Woul= d like to define new attributes to solave all issues….for the 3rd iss= ue, to address “framed” services like ‘acct-framed-ipv4-i= nput/output-*’

* Asks if it can be= adopted as an informational document? And if so, what’s the right ap= proach?

* Bernard discusses, orginal 316= 2 only handles a specific set (PPP access) of IPv6, then added prefix deleg= ation. There’s another draft to deal with other scenarios (like dsl a= nd wlan)….and expanding (like 6rd) and expanding attributes as IPv6 d= eployments come to light. Part of the problem is 3162 only addresses one sc= enario….so are the existing definitions used to fit the new scenarios= ?  Suggests that we hold on as we will be discussing issue #2 later in= this session.  But for issue #1 asks Alan on the accounting issue, wi= th adding IPv6. Alan comments that the attributes are global, there was a t= hread before; in 2866 don’t have anything to do with IPv4 other than = getting an IPv4 address in the packet. So, what do you do when user has mul= tiple IP addresses? Given specs are silent, there are diff implementations.= Bernard agrees.acct info is for all of the user’s traffic but “= ;what that means” is based on the implementation.

* Jouni Kohren comments: in mobile network, there’s a= similar situation. They use what is done today, but there are also other a= ttributes to tell the service type based on that authZ happens.  At le= ast for mobile networks its similar and we have used what’s there usi= ng vendor AVPs.

* Bernard asks: how do y= ou handle the accounting packets?  Jouni responds:  based on time= .but it’s really a don’t care if its v4 or v6.

* Bernard suggests another way to do the accounting if w= ant to separate v4 or v6 but Jacni says its too tricky.

* Jacni suggests that perhaps we allocate one new attribute= for “framed” service?

* Ste= fan wonders whether that would lead? As RADIUS doesn’t look at distin= ctions (e.g no wired vs wireless), and this is doing it at the IP layers an= d concerned that it may require too many new attributes

* Jacni suggests can we just do the “framed” se= rvices?

* Alan also expresses similar co= ncerns to Stefan’s comments.  There’s another scenario tha= t uses multiple sessionID to track the multiple flows as opposed to allocat= ing new attributes

* Bernard understands= multi-session id, but how to distinguish v4 vs v6?

* Alan says session ID would also have the ipv4 addressing and= correlate the multi-session ID to correlate the 2 sessions (1 being v4 and= 2nd v6).

* Leaf (Huawei) comments on te= chnical report that is also looking at the tracking for the same session th= at has 2 traffic flows. The access server has separate queues one for each = v4 vs. v6….that means the access server should have the ability of pr= oviding the distinct information to report to the AAA server and allow for = different accounting policies.

* Bernard= : question to the floor was whether we should take this as a WG item? = So, should issue 3 be a WG to solve this problem?

* Leaf comments that question is whether we can take this info= rmational?  Jacni says its OK

* Ber= nard wants to take the question: should we work on issue #3?  2 in fav= or, none against. Alan has no opinion

* = Stefan comments that what could be done is to specify it in a general way s= o that detailed reports could be sent (against doing it just for v4 and v6 = attributes).

* Bernard thinks there̵= 7;s some interest.so we can take it on in the mail list and figure out how = to move forward.

* Jacni comments that u= nderstands Stefan’s concern but it is a high priority item to them.

* Bernard understands that we have a shor= t timeframe especifally for v6.

* Stefan= suggests that a VSA can be used until a proper solution is in place.<= /o:p>

* Jouni suggests to use VSA too.

* Bernard closes by stating it will go to the mail l= ist.

 

 

5.RADIUS Attributes for Du= al Stack Access, L. Yeh

http://tools.ie= tf.org/html/draft-yeh-radext-dual-stack-access

- Notes that draft is updated to -02, idea is roughly the same<= /o:p>

- This proposal helps address Jacni’s i= ssue but also questions whether other attributes beyond the traffic count a= re needed.

- Suggests there’s anot= her deployment scenario whereby you want to allow the operator (e.g. AAA se= rver) for the type of user (e.g. dual stack, v4 only, v6 only).<= /p>

- Proposes a list of User-Type values for handling = service distinctions.

- Bernard thanks f= or the comprehensive list.  Notes another distinction of how the routi= ng goes from the nas to the cpe.  There’s also the framed-ipv6 r= oute proposed which is what the nas advertises to the cpe.

- Leaf notes that it’s not about the route, this i= s about the accounting.

- Asks if IPoE n= eeds another set of codes? And similarly adding attributes on the NAS-Port-= Type or Framed-Protocol (with IPoE).

- M= entions traffic statistic attribute values may be needed as well and propos= es a new set for the use of dual stack.

= - Closes on whether these should be taken on as a WG item.

- Stefan comments regarding the accounting express conce= rn on the proliferation of the different attributes.

- Leaf states that the accounting is for per user.<= /p>

- Bernard asks if further comments?  Notes tha= t we agreed to look at statistics, but on the user-types don’t need a= n explicit type as there’s a way to distinguish today, we may need to= have means to distinguish NAS types. But am not sure that we want another = draft that discusses existing things already, so another one can cause furt= her confusion.

- Leaf counters that we n= eed to solve current issues as operators need to change the type of use (us= er-type), so we need AAA server to tell access server the user-type.

- Bernard comments that there should already b= e a mechanism to help do that.

- Nancy a= sks is it just  using the current attributes to distinguish the user t= ype

- Leaf wants new attributes to tell = what kind of user it is.

- Stefan points= that current inspection of the current attributes already assigned, then o= ne can uniquely define the user type.

- = Bernard comments that the attributes today are already used to assign the s= ervice.

- Leaf comments that the NAS onl= y has the pool names, want the AAA server to just tell the NAS the user typ= e

- Bernard is confused on what attribut= es are needed.

- Stefan understands that= AAA server doesn’t give out the pool, just indication to NAS a prefi= x, it doesn’t have the framed attributes.

- Bernard clarifies that server doesn’t have the pool….= and the pool name should already map between NAS and AAA server.  Sugg= ests that we should bring it to the list as we agreed to work on the accoun= ting part, but we need to better understand on what is missing to require t= he user type.

 

6. RADIUS Attributes for IPv6 Access Networks, W. Dec =

http://tools.ietf.org/html/draft-ietf-radext= -ipv6-access

- Bernard notes that we nee= d a bit or work to resolve Wojciech’s issue.  Slides are present= , so Bernard reviews them:

- Bernard des= cribes problem: 3162 defines framed-ipv6-route, in 2865 also has framed-rou= te (for ipv4) and framed-routing to describe options for how IGP should beh= ave. 3162 doesn’t define the *-routing.

- There doesn’t seem to have an implication that IGP has been e= nabled…3162 defines route-ipv6-information attributes.  Request = is to clarify difference between framed-ipv6-route and route-ipv6-informati= on attribute.

- Bernard asks if there ar= e implementations of this so we can understand what is actually done today?=

- Leaf asks which RFC? Bernard notes it= s 3162 that defines framed-ipv6-route

- = This is the only issue holding up the RFC, so Bernard wants to gets this re= solved so that we can move forward without causing interop problems.

- Bernard solicits input.none is provided=

- Jouni mentions that they’ve implemen= ted IPv6 but ignore these attributes. Bernard asks what info is provided to= the RA?  They do use the framed-ipv6-prefix to the gateway….Ber= nard agrees that it would make sense.

- = RFC4191 is more specific routes draft.Bernard asks Jouni if they implement = today?  Answer: no

- Leaf comments = 3162 has a different format for the route-ipv6-information. The first only = has a text string, the purpose may be the same, but the formats are differe= nt.  So, the new draft could specify the prefix.

- Bernard would like to claim that framed-ipv6-route has the = same goals as framed-route. The new attribute is for the more specific rout= e while the other is for IGP.  Will bring this to the list to get cons= ensus.

 

7. Crypto-Agility Requirements for RADIUS, Bernard Aboba

http://tools.ietf.org/html/draft-ietf-radext-cry= pto-agility-requirements

- Document to c= apture requirements and requests for review in TRAC to close on this asap

- Open issue 89: keywrap and password hid= ing requirements

- If RADIUS is protecte= d as a whole, is keywrap needed?

- Stefa= n: is this an end to end keywrap vs. proxy?

- Bernard believes it is hop by hop.

- Stefan: if its end to end then there may be more benefit than if its jus= t hop by hop.

- Bernard: confidentiality= was not a requirement, so its possible that not the whole packet is encryp= ted, so keywrap would be needed.  So, we would want to keep this and c= larify it in the doc.

- Dan asks if ther= e’s a discussion on keywrap in future work? Since there’s Glen&= #8217;s draft as informational that perhaps we should move to standards spa= ce?  Bernard comments that its in the queue so it’s there.<= /o:p>

- Bernard suggests that we can do the writeup= to state that if RADIUS is protected, then keywrap is not needed; but if t= here’s no protection then keywrap can be used.

- Dan states that it makes sense, but need communication to th= e IESG that this is the resolution

- Iss= ue 90: process for publication and selection

- Proposal is to define process through experimental drafts to define = the mechanisms that can be used.

- With = these 2 resolved, then it can go to final WGLC.

 

8. RADIUS over TLS, Stefa= n Winter

http://tools.ietf.org/html/dra= ft-ietf-radext-radsec

- New draft submi= tted to address open issues except for “client id”

- Everything goes thru one port

- Auth server, acct server and dynauth server are separate e= ntities

- Client ID is hard as different= modes need different treatment: PSK vs X.509 fingerprint vs. X.509 proper = (e.g. full chain, OCSP verification)

- I= n RADIUS/UDP, client id =3D authZ used to exchange packets

- For RADIUS/TLS-PSK: there can be more than 1 NAS talki= ng

- Biggest diff where client id !=3D a= uthZ because the X.509 clients are unique identified by the issuer/serial n= umber. So, can have authZ based on client types.can have that info in the c= ert data (policyOID) or out-certificate (query to some directory)

- Bernard comments that it would be useful to com= municate an error to determine unauthorized certificate.  Stefan: in t= his case, the connection would just close.  Bernard suggests that TLS = error messages could also be used.  Stefan comments that he can look i= nto it

- Consequence to the spec:

* Stack needs to expose ID criteria to admin: = issuer/serial number

* Need to add text= /guidelines for AuthZ

- Bernard suggests= looking at “tls server id check” from Peter St Andre as it rel= ates to the dynamic discovery draft for how to delegate a server to a domai= n and verify the trust. Also talks about other attributes that should be lo= oked at

- Stefan would like to keep it s= imple by, say, looking at serial number only

- Dan speaking as contributor: there are many places in IETF discussin= g identities or places that can be looked at to get identity information.&n= bsp; Don’t know if and how whether the problem can be solved consiste= ntly given that there’s no single model.but would like to point out t= hat there are other places in IETF that also have this problem and may have= ideas to use

- Stefan notes that this d= ocument is still experimental and would like to look at how industry curren= tly looks and uses certificates

- Given = that there are more than 1 NAS as a potential, there’s the question o= f how a client ID can be used.

&nbs= p;

9. Dynamic Peer Discovery, Stefan Winter

http://tools.ietf.org/html/draft-ietf-rad= ext-dynamic-discovery

- No new revision = since last draft

- Given that there are = 3 separate entities, 3 labels are needed for auth, acct and dynauth

- Could look like: S-NAPTRs: radius.tls, radacc= t.tls, raddynauth.tls

- As a result can = now generate a new draft

- Jouni notes t= hat there is a similar draft in DIAMETER that is going to IESG. Is this dra= ft aligned with the one in DIAMETER?

- S= tefan notes that we are limited to 3.

- = Jouni notes that since there’s nothing official in diameter, will the= re be 2 different or can we keep them the same?

- Stefan notes that they are slightly different. Though radius coul= d just use “aaa” with no extension

 

10. RADIUS over DTLS, Alan= DeKok

http://tools.ietf.org/html/draft-= ietf-radext-dtls

- No real changes since= last IETF.current draft may be expired so need to update it

=

- Open issues: need to resync with RTLS draft, double = check consistency. Port reuse issues, want review from Stig Venaas regardin= g the radsecproxy

- There are 3 implemen= tations radsecproxy, jradius, freeradius

- Main dependency is the rtls sync

- St= efan notes that the port number had been resolved to only use 1 port. Alan = agrees, just notes that the draft needs to be updated to reflect the new ou= tcome

 

11. RADIUS Protocol Extensions, Alan DeKok

http://tools.ietf.org/html/draft-ietf-radext-radius-extensions=

- Almost same presentation as IETF 79.t= his has been discussed for many years

- = Review of current proposal: change 1 byte; take 1 byte from value to extend= type. Description of the new format to allow for 1.5K new attributes, allo= w grouping via TLS, standard way to having “long” attrs and new= means for allowing vendors to have long VSA

- Bernard notes that this kind of issue has arisen for a while now and= the hope that this one is more palatable to push forward.  Need to br= ing it to people who want it.

- Stefan n= otes that when working on accounting and such those would be a good candida= te for grouping them per this proposal.

= - Bernard notes that this may be good incentive to get the ones requesting = for new attributes to use this new way.

= - Mauricio comments that if we want people to use this, we need to wrap thi= s one up first so that we can then get the proposals for new attribute allo= cation to use this new format.

- Bernard= states that there were some that still did not want to use this…woul= d be better if they would sign up willingly

- Alan suggests that any new specs coming out, would be inclined to pus= h them hard to use this

- About 7 people= have read the draft

- Dan comments that= it is useful, but at this point can not make it a showstopper on other pro= posals until this document has been ratified.

 

 

12. Discussion and Wrap-up

- Due to several topics running over, there was no time left to review ne= xt steps.  Chairs commented that several action items had been identif= ied and would be driven from the meeting notes.

= = --_000_9BC2F7926B33FE4AB10D69891D58FC1C5B555A194EGVW0671EXCame_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 01 Apr 2011 11:01:07 +0000 Message-ID: <4D95B038.8000706@deployingradius.com> Date: Fri, 01 Apr 2011 13:00:08 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter CC: "radiusext@ops.ietf.org" Subject: Re: Notification: draft-winter-radext-fancyaccounting-00 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Stefan Winter wrote: > as discussed, I've written up the idea about fancy accounting in an I-D. > URL: > > https://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting/ > > Please comment if you find the time - especially those people who need > the IPv6 accounting! Nice! I have some nits on the formatting, but nothing serious. The only substantial comment is that you've defined Acct-Traffic-Class-Input-Octets, but the examples use Acct-Input-Octets, instead. Another idea would be to have the description of the flow leverage the NAS-Filter-Rule syntax. (RFC 4849). That would make it easy for everyone to describe the flows. > idnits told me that the Intended Status can't possibly be > Standards-track - RADIUS Accounting itself is only informational :-/ Well, that can be fixed somehow. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: