Subject: RADEXT WG - IETF 81 preliminary meeting notes

From: "Sanchez, Mauricio (HP Networking)" <[email-masked]>
Date: Mon, 25 Jul 2011 23:29:42 +0100

These are the preliminary notes for IETF 81. Many thanks to Mark Jones for taking notes this morning.  Comments/corrections welcome.

-MS

--------------------------------------------------------------------------------------------------------------
RADEXT WG Minutes
IETF 81
Quebec, Canada
Monday, July 25th, 2011
Meeting started 9:02 AM and ended 11:27AM EDT. Approximately 35 individuals in meeting

Chairs:
Jouni Korhonen <[email-masked]>
Mauricio Sanchez <[email-masked]>

1. Preliminaries

Agenda slides: http://www.ietf.org/proceedings/81/slides/radext-3.pptx

Attendees: Bluesheets circulated.
Note Well
Note Takers
- Note volunteer Mark Jones
Jabber scribe
- Alan DeKok jabber scribe
Agenda bash
- IPv6, enhancements, security grouped item.  No changes to agenda made

****************************************************************

2. Radius Extensions for CGN Configurations, Dean Cheng
http://www.ietf.org/id/draft-cheng-behave-cgn-cfg-radius-ext-00.txt

Presented by Dean Cheng.
Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-2.ppt
Hannes Tschofenig: Slide 3: Do you now assume DHCP between end host and NAT?
Dean Cheng: Service Request is a general term but no change.
Hannes Tschofenig: What happens when NAT runs out of ports?
Dean Cheng: Number of ports are configured on server. It is used to limit.
Hannes Tschofenig: What happens in failure case? i.e. you reach restriction.
Dean Cheng: AAA only returns limits. If use wants more ports, ICMP can be used to indicate
error.
Hannes Tschofenig: How do you ensure ICMP reaches end host?
Dean Cheng: OK. We can discuss offline.
Mauricio Sanchez:  Slide 5: Did you read RFC6158 RADIUS Guidelines
Dean Cheng: Yes. Need some help on these encoding wrt RADIUS guidelines.
---
Questions:
Mauricio Sanchez: Where is this in BEHAVE WG?
Dean: Result of merge of two drafts to BEHAVE. Chair suggested to present in RADEXT because
comments received were on RADIUS aspects
Dan Romanascu: Is this a charter item in BEHAVE.
Dean: No. Still be chartered. Chair said it is within scope of BEHAVE.
Dan: What do you need from RADEXT? Advisor? WGLC?
Dean: BEHAVE suggest to present in RADEXT to get comments.
Dan: In draft, need to expand acronyms.
Hannes: (1) Need to define bigger picture. NAT behaviour when it runs out of resources. Need to know why it fails. (2) AAA client does not live on NAT. DHCP and NAT are mashed together but it depends how these are related.
Dean: AAA client is not changed. NAT44 must be co-located with BNG.
Hannes: Very special scenario.
Dean: If CNG (NAT44) not colo with BNG this falls apart.
Dan: Any other mechanisms to configure CNG other than this draft?
Dean: No change. Only leverages existing deployment.

****************************************************************

3. RADIUS Attributes for IPv6 Access Networks, Wojcieh Dec
http://tools.ietf.org/html/draft-ietf-radext-ipv6-access
Presented by Mauricio Sanchez.
Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-5.ppt
Questions:
Leaf  Yeh: In new version, new attribs. Only sends name of pool. DHCP already has a pool.
Doesn't think this is necessary. Attributes in v4 can already do this. There is no need to a v6 pool name.
Leaf agreed to send concern to list
Roberta Maglione: It is just a pool name. Semantics are different.
Bernard Adoba: One is a prefix pool and the other is an address pool. May need to do both at
once.
Leaf: But it is only a string. So DHCP server can use name format is disambiguate.
Mauricio Sanchez: Sounds like valid reason for these two attributes. Please bring comments to
list.
****************************************************************
4. RADIUS accounting for traffic classes, Stefan Winter
http://tools.ietf.org/html/draft-winter-radext-fancyaccounting
Presented remotely by Stefan Winter.
Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-4.pdf
Other issues:
Mark Jones: We don't need to include filter definition in accounting stream. Just include filter name (bucket label) in the accounting stream.
Stefan: Ok. Nice and simple. Works for me.
Dan Romanascu : Reuse definitions from RFC4898
Mauricio Sanchez: Concerned about number of drafts to progress. Does not want to oversubscribe WG. Poll: Who is interested in this work? Who will help out if WG item?
Show of hands in room:
Relevant and useful: No interest.
Stefan: Will let draft expire unless someone comes forward with interest.
Mauricio Sanchez: Thanks for spending time on this.

****************************************************************

5. Dynamic Peer Discovery, Stefan Winter
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery
Presented by Stefan Winter.
Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-0.pdf
Stefan Winter: Asked about IESG comments on DIME equiv.
Mark Jones: IESG DISCUSS is on format of Application Protocol Tag. Concern was that the current format indicates a structure.
Stefan Winter: Any IESG comments on Service Tag?
Mark Jones: No. Just protocol tags.
Comments or questions:
Dan Romanascu: Jouni, Can you comment on issues encountered in DIME?
Jouni Korhonen: Need to solve this in DIME. Mark gave summary of IESG concern.
Dan Romanascu: Do we need to stop work in this?
Jouni Korhonen: No.
Mark Jones: Confident that labels will be resolved. Not doing anything unnatural with our original labels. No reason to stop work on this.
****************************************************************

6. RFC4282bis, Alan DeKok
Presented by Alan Dekok
Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-6.ppt
Dan Romanascu: So  4282bis strips out internationization, right? How is this separation being followed in other groups?
Alan Dekok: Working with PRECIS on that aspect.
****************************************************************
7. RADIUS Protocol Extensions, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radius-extensions
Presented by  Alan Dekok.
Slidedeck:  http://www.ietf.org/proceedings/81/slides/radext-8.ppt
Dan Romanascu: So this is a new type and is not backwards compatible?
Alan: Backwards compatible for proxies that treat as an opaque blob. IANA says these types (241-244) are not used but they are used in the real world. Tough.
Sam Hartman: I have a draft in abfab requiring this and would like to see this go fwd. Please don't call it an OID though.
 Alan Dekok: Audit shows that this should handle allocation needs for the foreseeable future.
So we don't need adhoc formats. Just help them implement this new format.
****************************************************************

8. RADIUS over DTLS, Alan DeKok
http://tools.ietf.org/html/draft-ietf-radext-dtls
Presented by  Alan Dekok.
Slidedeck:  http://www.ietf.org/proceedings/81/slides/radext-7.ppt
No questions.
****************************************************************
9. RADIUS over TLS, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec
Presented remotely by Stefan Winter.
Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-1.pdf
Mauricio: Agree that it is ready for WGLC. Any other comments/questions?
Dan Romanascu: TCP port allocation. Intention is to reuse port for radsec. So are there any  backwards compatability issues.
Stefan Winter: No. Old radsec is the format for RADIUS/TLS. OCS said once RFC is published they will change their implementation to do it this way.

****************************************************************
(Margaret requested to present at RADEXT after agenda bashing had occurred and WG chairs accepted presentation request)

10. Multihop Federations (Trust Router).
Margaret Wasserman
Slidedeck: http://www.ietf.org/proceedings/81/slides/radext-9.pptx
Philip Hallam-Baker: Looks like UUCP. It was replaced with DNS. Anything that looks like a  namespace should be using DNS. Look at Bridge CAs. Used in PKI space. Lots of univ are in Bridge Cas. Can also use Rulebook structure so never need a path of more than 2 so don't need
BGP.
Margaret Wasserman: This is not about getting to every node. Only about getting between nodes in AAA infrastructure. They are all IP nodes and already in BGP
Philip Hallam-Baker: You will find you use only 10% of BGP and not the interesting part.
Hannes: Draft addresses some of the issues. Relationship are not purely mechanical. Don't want to talk to everyone. Like SAML, Liberty Alliance. Come up with circle of trust. They exist in AAA space. The Trust Router setup allows shortcuts.
Alan Dekok: Echo Hannes. Need to represent biz relationships: Who to talk to depends on who is asking. Still have questions on the details
Margaret Wasserman: This lets you put policy in interesting places (local trust router). E.g. not route should Russian nodes even if the route is shorter.
Klaas Wierenga: This work is motivated by problems seen in large scale SAML deployments. Esp to express complex polices around who you want to trust. Share some of Philips concerns
Philip Hallam-Baker: Working on this problem for 15yrs. Similar to other approaches that have already been implemented.
Sam Hartman: This is in the draft.
Philip: Why not in the presentation?
Margaret Wasserman: Not accepted as WG item in abfab. Feedback required on abfab list.
Hannes: Also talking to VOIP folks who are reusing BGP concepts.
Margaret Wasserman: we have not written these protocols. If a better way, please explain.
Philip Hallam-Baker: Thinking as a CA. Someone has to manage it and money will flow around. The task of introduction is going to be paid. May want to pay premium to find a path with a higher degree of trust.
Margaret Wasserman: Allows for biz intelligence at many different layers.
Philip Hallam-Baker: Contracts will determine this. Don't need this hop by hop. Can take this offline.
Margaret Wasserman: Would be interested in those pointers to approaches already tried.
Klaas Wierenga: This goes beyond abfab. So AD pushed us to present in other groups that see the same type of problem. Welcome a broad discussion.
Margaret Wasserman: On agenda in abfab on Friday morning.

****************************************************************

11. Email list server migration
Dan Romanascu: Please explain what it means for people on the list.
Mauricio: Nothing. Should be transparent. Got a process for archive migration.
Jouni: Auto move of subscribers to new list. Emails will be forwarded between lists.
Secretary will move archives.
Dan: On behalf of doubters: Can you explain migration of archives?
Mauricio: Others (Fred Baker) created the process for painless migration of archives. So we
Dan: Do references on the tracker need to change?
Jouni: Direct links to archives need to be updated.
Mauricio: Will need to look into that and make sure it is remedied.

****************************************************************
12. Next Steps: WG Chairs & ADs
WG Goals/Milestones status
No questions

---

From: Leaf yeh <[email-masked]>
Date: Tue, 26 Jul 2011 11:37:41 +0000

I've sent a question of clarification to the mailing list agaisnt draft-ietf-radext-ipv6-access-05. Pls. refer to https://ops.ietf.org/lists/radiusext/2010/msg00959.html.

Sorry for my poor expression in the Radext session. I'd like to clarify my words in the meeting notes here.

> Leaf  Yeh: In new version, new attribs. Only sends name of pool. DHCP already has a pool.

I meant the attribute of Framed-Pool (88, section 5.18 of RFC2869) here, which is used to send the pool name from AAA server to NAS server, to indicate the right pool employed or configured on NAS.

> Doesn’t think this is necessary. Attributes in v4 can already do this. There is no need to a v6 pool name.
> Bernard Adoba: One is a prefix pool and the other is an address pool. May need to do both at once.

I meant the NAS can interprect the pool name recevived from AAA server for each kind of usage, such as IPv4 PPP address pool, IPv6 SLAAC prefix pool, IPv6 DHCPv6 address pool or DHCPv6-PD prefix pool.

list.

Best Regards,
Leaf

________________________________

发件人: [email-masked] [[email-masked]] 代表 Sanchez, Mauricio (HP Networking) [[email-masked]]
发送时间: 2011年7月26日 6:29
到: [email-masked]'
主题: RADEXT WG - IETF 81 preliminary meeting notes

-MS

Chairs:

1. Preliminaries

Presented by Dean Cheng.

Doesn’t think this is necessary. Attributes in v4 can already do this. There is no need to a v6 pool name.
Mark Jones: We don’t need to include filter definition in accounting stream. Just include filter name (bucket label) in the accounting stream.

Sam Hartman: I have a draft in abfab requiring this and would like to see this go fwd. Please don’t call it an OID though.
So we don’t need adhoc formats. Just help them implement this new format.

Philip Hallam-Baker: Looks like UUCP. It was replaced with DNS. Anything that looks like a  namespace should be using DNS. Look at Bridge CAs. Used in PKI space. Lots of univ are in Bridge Cas. Can also use Rulebook structure so never need a path of more than 2 so don’t need
Hannes: Draft addresses some of the issues. Relationship are not purely mechanical. Don’t want to talk to everyone. Like SAML, Liberty Alliance. Come up with circle of trust. They exist in AAA space. The Trust Router setup allows shortcuts.
Philip Hallam-Baker: Contracts will determine this. Don’t need this hop by hop. Can take this offline.

---

From: Jacni Qin <[email-masked]>
Date: Wed, 27 Jul 2011 01:47:03 +0800

Hi,

A quick comment, I'm concerned by the "Stateful-IPv6-Address-Pool"
attribute, why can't we re-use the Frame-* one?

Cheers,
Jacni

2011/7/26 Leaf yeh <[email-masked]>

>  I've sent a question of clarification to the mailing list agaisnt
> draft-ietf-radext-ipv6-access-05. Pls. refer to
> https://ops.ietf.org/lists/radiusext/2010/msg00959.html.
>
>
>
> > Leaf  Yeh: In new version, new attribs. Only sends name of pool. *DHCP*already has a pool.
>
>
>
> I meant the attribute of Framed-Pool (88, section 5.18 of RFC2869) here,
> which is used to send the pool name from AAA server to NAS server, to
> indicate the right pool employed or configured on NAS.
>
>
>
> > Leaf: But it is only a string. So *DHCP server* can use name format is
> disambiguate.
>
>
>
> I meant the NAS can interprect the pool name recevived from AAA
> server for each kind of usage, such as IPv4 PPP address pool, IPv6 SLAAC
> prefix pool, IPv6 DHCPv6 address pool or DHCPv6-PD prefix pool.
>
>
>
> ------------------------------
>
> *发件人:* [email-masked] [[email-masked]] 代表
> Sanchez, Mauricio (HP Networking) [[email-masked]]
> *发送时间:* 2011年7月26日 6:29
> *到:* [email-masked]'
> *主题:* RADEXT WG - IETF 81 preliminary meeting notes
>
>   These are the preliminary notes for IETF 81. Many thanks to Mark Jones
> for taking notes this morning.  Comments/corrections welcome.
>
>
>
> -MS
>
>
>
>
> Hannes: (1) Need to define bigger picture. NAT behaviour when it runs out
> of resources. Need to know why it fails. (2) AAA client does not live on
> NAT. DHCP and NAT are mashed together but it depends how these are related.
>
> Mark Jones: We don’t need to include filter definition in accounting
> stream. Just include filter name (bucket label) in the accounting stream.
>
> Mauricio Sanchez: Concerned about number of drafts to progress. Does not
> want to oversubscribe WG. Poll: Who is interested in this work? Who will
> help out if WG item?
>
> Show of hands in room:
>
> Mark Jones: IESG DISCUSS is on format of Application Protocol Tag. Concern
> was that the current format indicates a structure.
>
> Mark Jones: Confident that labels will be resolved. Not doing anything
> unnatural with our original labels. No reason to stop work on this.
>
> Dan Romanascu: So  4282bis strips out internationization, right? How is
> this separation being followed in other groups?
>
> Alan: Backwards compatible for proxies that treat as an opaque blob. IANA
> says these types (241-244) are not used but they are used in the real world.
> Tough.
>
> Sam Hartman: I have a draft in abfab requiring this and would like to see
> this go fwd. Please don’t call it an OID though.
>
> Dan Romanascu: TCP port allocation. Intention is to reuse port for radsec.
> So are there any  backwards compatability issues.
>
> Stefan Winter: No. Old radsec is the format for RADIUS/TLS. OCS said once
> RFC is published they will change their implementation to do it this way.
>
>
>
> (Margaret requested to present at RADEXT after agenda bashing had occurred
> and WG chairs accepted presentation request)
>
>
>
> Philip Hallam-Baker: Looks like UUCP. It was replaced with DNS. Anything
> that looks like a  namespace should be using DNS. Look at Bridge CAs. Used
> in PKI space. Lots of univ are in Bridge Cas. Can also use Rulebook
> structure so never need a path of more than 2 so don’t need
>
> BGP.
>
> Margaret Wasserman: This is not about getting to every node. Only about
> getting between nodes in AAA infrastructure. They are all IP nodes and
> already in BGP
>
> Hannes: Draft addresses some of the issues. Relationship are not purely
> mechanical. Don’t want to talk to everyone. Like SAML, Liberty Alliance.
> Come up with circle of trust. They exist in AAA space. The Trust Router
> setup allows shortcuts.
>
> Alan Dekok: Echo Hannes. Need to represent biz relationships: Who to talk
> to depends on who is asking. Still have questions on the details
>
> Margaret Wasserman: This lets you put policy in interesting places (local
> trust router). E.g. not route should Russian nodes even if the route is
> shorter.
>
> Klaas Wierenga: This work is motivated by problems seen in large scale SAML
> deployments. Esp to express complex polices around who you want to trust.
> Share some of Philips concerns
>
> Philip Hallam-Baker: Working on this problem for 15yrs. Similar to other
> approaches that have already been implemented.
>
> Philip Hallam-Baker: Thinking as a CA. Someone has to manage it and money
> will flow around. The task of introduction is going to be paid. May want to
> pay premium to find a path with a higher degree of trust.
>
> Klaas Wierenga: This goes beyond abfab. So AD pushed us to present in other
> groups that see the same type of problem. Welcome a broad discussion.
>