Subject: Minutes of RADEXT meeting at IETF 80

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Fri, 1 Apr 2011 12:00:39 +0000

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 individuals in meeting.

Chairs:  Bernard Aboba <[email-masked]>
                Mauricio Sanchez <[email-masked]>

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 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.  So, now as a result, there is an open process to find a co-chair to work 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 2868 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 since 3575 is more recent and the request is justified.  But need IESG perspective review by WG.
- Bernard suggests to get a sense of this group and then 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 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.

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 propagate this info.
- Proposal to add a IPv6-6rd-config attribute.  A draft was presented by the 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.  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.
- 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 several domains on NAS like "v4, v6 or dual stack" with "framed host, or home network" 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 all issues....for the 3rd issue, to address "framed" services like 'acct-framed-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 other scenarios (like dsl and wlan)....and expanding (like 6rd) and expanding 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 issue #2 later in this session.  But for issue #1 asks Alan on the accounting issue, 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 than getting an IPv4 address in the packet. So, what do you do when user has multiple 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 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" service?
* Stefan wonders whether that would lead? As RADIUS doesn't look at distinctions (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 another scenario that uses multiple sessionID to track the multiple flows as opposed 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 the 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 tracking 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 should 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 item?  So, should issue 3 be a WG to solve this problem?
* Leaf comments that question is whether we can take this informational?  Jacni says its OK
* Bernard wants to take the question: should we work on issue #3?  2 in favor, 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 v6 attributes).
* Bernard thinks there's some interest.so we can take it on in the mail list and figure out how to move forward.
* Jacni comments that understands Stefan's concern but it is a high priority 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 place.
* 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 other attributes beyond the traffic count are needed.
- Suggests there's another deployment scenario whereby you want to allow the 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 proposes 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 proliferation 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 statistics, 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 already, so another one can cause further confusion.
- Leaf counters that we need to solve current issues as operators need to change the type of use (user-type), so we need AAA server to tell access server 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 user type
- Leaf wants new attributes to tell what kind of user it is.
- Stefan points that current inspection of the current attributes already assigned, 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 to 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 indication 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 bring 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.  Slides are present, so Bernard reviews them:
- Bernard describes problem: 3162 defines framed-ipv6-route, in 2865 also has framed-route (for ipv4) and framed-routing to describe options for how IGP should behave. 3162 doesn't define the *-routing.
- There doesn't seem to have an implication that IGP has been enabled...3162 defines route-ipv6-information attributes.  Request is to clarify difference between framed-ipv6-route and route-ipv6-information attribute.
- Bernard asks if there are implementations of this so we can understand what is actually done today?
- Leaf asks which RFC? Bernard notes its 3162 that defines framed-ipv6-route
- 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 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 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 other 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 want 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 space?  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 protected, then keywrap is not needed; but if there's no protection then keywrap can be used.
- Dan states that it makes sense, but need communication to the IESG that this is the resolution
- Issue 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, 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.509 fingerprint vs. X.509 proper (e.g. full chain, OCSP verification)
- In RADIUS/UDP, client id = authZ used to exchange packets
- For RADIUS/TLS-PSK: there can be more than 1 NAS talking
- Biggest diff where client id != authZ because the X.509 clients are unique identified by the issuer/serial number. So, can have authZ based on client types.can have that info in the cert data (policyOID) or out-certificate (query to some directory)
- Bernard comments that it would be useful to communicate an error to determine 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 only
- Dan speaking as contributor: there are many places in IETF discussing identities 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 places 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 look 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, acct 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 IESG. 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 be 2 different or can we keep them the same?
- Stefan notes that they are slightly different. Though radius could 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 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. Alan agrees, just notes that the draft needs to be updated to reflect the new 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 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, allow 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 good 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 this one up first so that we can then get the proposals for new attribute allocation 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 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 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.

---

From: Peter Deacon <[email-masked]>
Date: Fri, 1 Apr 2011 11:18:15 -0700 (Pacific Daylight Time)

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

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

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

---

From: Alan DeKok <[email-masked]>
Date: Sat, 02 Apr 2011 08:32:48 +0200

> essentially TLVs to remove external dependencies?

  It's a good idea, I think.

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>