Subject: [radext] [IANA #935820] Protocol Action: 'RADIUS Extensions for IP Port Configuration and Reporting' to Proposed Standard (draft-ietf-radext-ip-port-radius-ext-16.txt)

From: "Amanda Baber via RT" <[email-masked]>
Date: Fri, 11 Nov 2016 00:04:46 +0000

Dear Authors,

The IANA Services Operator is not yet able to complete the registry actions for this document. We still need an answer to this question:

Section 7.3 calls for registrations in the "RADIUS TLVs" registry, but we haven't been able to locate a registry by that name. (Please see http://www.iana.org/protocols for a list.)

Is this document creating a registry called RADIUS TLVs? If so, this section needs to note that it's creating a registry, provide a registration procedure (see RFC 5226), and let us know 1) whether value 0 should be listed as "Unassigned" or "Reserved" and 2) what the registry's maximum value is, if it has one.

Best regards,

Amanda Baber
Lead IANA Services Specialist
PTI

---

From: Dean cheng <[email-masked]>
Date: Fri, 11 Nov 2016 03:04:20 +0000

Hi Amanda,

There are several things that require IANA actions
relevant to Radius as follows:

1) In Section 3.1.1, 3.1.2 and 3.1.3, we use the
   number "241" for the "Type" field. That needs
   to be confirmed by IANA.
  
   In Section 7.2, there are TBD1 (also in Section 3.1.1),
   TBD2 (also in Section 3.1.2) and TBD3 (also in
   Section 3.1.3), which need values to be assigned
   by IANA. 

   Once the above is done, new registries can be added to
   http://www.iana.org/assignments/radius-types/radius-types.xhtml
   as the following:

      241.TBD1   IP-Port-Limit-Info     [RFCxxxx]
      241.TBD2   IP-Port-Range          [RFCxxxx]  
      241.TBD3   IP-Port-Forwarding-Map [RFCxxxx]

   According to the availability in the registry,
   values in {5-25} and {27-240} can be chosen.

2) Section 7.3 proposes to assign sequentially the number
   from 1 to 11 inclusively to the eleven Radius TLV types.
   Refer to https://tools.ietf.org/html/rfc6929#section-2.7.3
   for TLV Identifiers.

   The "type" field is 8-bit long so there are possibly 256
   values. RFC6929 does not say the value "0" is "Unassigned"
   or "Reserved". In the Radius registry, the value "0" for
   attribute 241.1 is "Reserved". For consistency, I'd suggest
   to follow the same. The maximum value is 256. 

   Note each TLV in Section 7.3 may have more than one parent
   Radius attributes (e.g., 241.TBD1.1 and 241.TBD2.1). Therefore
   I'm not sure if these TLVs should go to Radius registry
   (Section 7.3 only requests for "allocation" for TLV types).

   If need to define these TLV types in the registry, it must
   say that these TLVs are independent and may associate with
   more than one attributes; but I don’t see any example like
   this in current registry.  

   Alan - what is your opinion?

Regards
Dean

> -----Original Message-----
> From: Amanda Baber via RT [mailto:[email-masked]]
> Sent: Thursday, November 10, 2016 4:05 PM
> Cc: [email-masked]
> Subject: [IANA #935820] Protocol Action: 'RADIUS Extensions for IP Port
> Configuration and Reporting' to Proposed Standard (draft-ietf-radext-
> ip-port-radius-ext-16.txt)
> 
> Dear Authors,
> 
> The IANA Services Operator is not yet able to complete the registry
> actions for this document. We still need an answer to this question:
> 
> Section 7.3 calls for registrations in the "RADIUS TLVs" registry, but
> we haven't been able to locate a registry by that name. (Please see
> http://www.iana.org/protocols for a list.)
> 
> Is this document creating a registry called RADIUS TLVs? If so, this
> section needs to note that it's creating a registry, provide a
> registration procedure (see RFC 5226), and let us know 1) whether value
> 0 should be listed as "Unassigned" or "Reserved" and 2) what the
> registry's maximum value is, if it has one.
> 
> Best regards,
> 
> Amanda Baber

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Nov 2016 10:07:49 -0500

>   to follow the same. The maximum value is 256. 

  https://tools.ietf.org/html/rfc6929#section-10

   Allocation of an Attribute Type value "TYPE" using the new "Extended
   Type" format results in allocation of 255 new Attribute Type values
   of format "TYPE.1" through "TYPE.255".

i.e. zero is not for allocation.

>   Alan - what is your opinion?

  This is a new thing to RADIUS.

  I suggest creating a new RADIUS TLV registry:

name: RADIUS IP Port Configuration and Reporting TLVs

contents: all of the TLVs which have more than one parent.

Then, each parent TLV can be marked as NOT having child attributes.  Instead, they should be marked as using the new registry for their children.

  Alan DeKok.

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Sat, 12 Nov 2016 14:48:48 +0000

Hi,

On Fri Nov 11 15:08:15 2016, [email-masked] wrote:
> Then, each parent TLV can be marked as NOT having child attributes.
> Instead, they should be marked as using the new registry for their
> children.

Is this in addition to the action in Section 7.3, or instead of the action in Section 7.3?

If the latter, please send us a new version of the section. It should tell us to create a registry and provide the following: 

- the name of the registry
-  the registration procedure for the registry (see RFC 5226)
- the initial contents of the registry (including a definition for value 0 and the maximum value)

For a recent example of a document that creates a registry, see https://tools.ietf.org/html/rfc7361#section-7.2 or https://tools.ietf.org/html/rfc7688#section-6.2.1. 

thanks,
Amanda

---

From: Dean cheng <[email-masked]>
Date: Mon, 14 Nov 2016 18:17:17 +0000

Hi Amanda,

Thanks for the message. We've just made changes in
Section 7.3 according to the suggestion.

If the updates OK, should we upload a new revision
(17.txt) at this time?

Regards
Dean

> From: radext [mailto:[email-masked]] On Behalf Of Amanda Baber
> via RT
> Sent: Saturday, November 12, 2016 6:49 AM
> Subject: [radext] [IANA #935820] Protocol Action: 'RADIUS Extensions
> for IP Port Configuration and Reporting' to Proposed Standard (draft-
> ietf-radext-ip-port-radius-ext-16.txt)
> 
> Hi,
> 
> > > The "type" field is 8-bit long so there are possibly 256 values.
> > > RFC6929 does not say the value "0" is "Unassigned"
> > > or "Reserved". In the Radius registry, the value "0" for attribute
> > > 241.1 is "Reserved". For consistency, I'd suggest  to follow the
> > > same. The maximum value is 256.
> >
> > > Note each TLV in Section 7.3 may have more than one parent Radius
> > > attributes (e.g., 241.TBD1.1 and 241.TBD2.1). Therefore I'm not
> sure
> > > if these TLVs should go to Radius registry (Section 7.3 only
> > > requests for "allocation" for TLV types).
> > >
> > > If need to define these TLV types in the registry, it must say that
> > > these TLVs are independent and may associate with more than one
> > > attributes; but I don’t see any example like
> If the latter, please send us a new version of the section. It should
> tell us to create a registry and provide the following:
> 
> For a recent example of a document that creates a registry, see
> https://tools.ietf.org/html/rfc7361#section-7.2 or
> https://tools.ietf.org/html/rfc7688#section-6.2.1.
> 
> thanks,
> Amanda
> 
> 
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Tue, 15 Nov 2016 00:24:54 +0000

Hi Dean,

I checked with the RFC Editor, and they said that this is a good time for the authors to upload a new revision. We can complete these actions before this has been uploaded, though. I'll contact you within a few hours to ask you to review the registries and confirm that everything was completed correctly. 

thanks,
Amanda

---

From: Dean cheng <[email-masked]>
Date: Tue, 15 Nov 2016 00:53:43 +0000

Hi Amanda,

OK, I'll take a look of the new registries, and send
you back the feedback.

Please send us once you are done (I'm in California 
time zone). 

For the draft itself, do we need to make any more 
changes - e.g., in the two examples you sent to us
below, the RFC7361 has text in Section 7.2 to 
reference RFC7361 itself (RFC7688 has similar reference), 
if we want to follow the same, we need to know the 
RFC number now?? 

Thanks
Dean

> Sent: Monday, November 14, 2016 4:25 PM
> I checked with the RFC Editor, and they said that this is a good time
> for the authors to upload a new revision. We can complete these actions
> before this has been uploaded, though. I'll contact you within a few
> hours to ask you to review the registries and confirm that everything
> was completed correctly.
> 
> thanks,
> Amanda
> 
> > Thanks for the message. We've just made changes in Section 7.3
> > according to the suggestion.
> >
> > > From: radext [mailto:[email-masked]] On Behalf Of Amanda
> > > Baber via RT
> > > > > attribute
> > > > Allocation of an Attribute Type value "TYPE" using the new
> > > > "Extended Type" format results in allocation of 255 new Attribute
> > > > Type values
> > > of
> > > > > I'm not
> > > > > If need to define these TLV types in the registry, it must say
> > > > > that these TLVs are independent and may associate with more
> than
> > > > > one attributes; but I don’t see any example like
> > > If the latter, please send us a new version of the section. It
> > > should tell us to create a registry and provide the following:
> > >

---

From: Dean cheng <[email-masked]>
Date: Tue, 15 Nov 2016 01:01:19 +0000

Hi Amanda,

Also, there are TBD1 etc. in the current draft
pending on value assigned by IANA. Should we
wait for the assignment and update the draft
accordingly too?

Thanks
Dean

> From: radext [mailto:[email-masked]] On Behalf Of Dean cheng
> Sent: Monday, November 14, 2016 4:54 PM
> To: [email-masked]
> Subject: Re: [radext] [IANA #935820] Protocol Action: 'RADIUS
> Extensions for IP Port Configuration and Reporting' to Proposed
> Standard (draft-ietf-radext-ip-port-radius-ext-16.txt)
> 
> Hi Amanda,
> 
> OK, I'll take a look of the new registries, and send you back the
> feedback.
> 
> Please send us once you are done (I'm in California time zone).
> 
> For the draft itself, do we need to make any more changes - e.g., in
> the two examples you sent to us below, the RFC7361 has text in Section
> 7.2 to reference RFC7361 itself (RFC7688 has similar reference), if we
> want to follow the same, we need to know the RFC number now??
> 
> Thanks
> Dean
> 
> > Subject: [IANA #935820] Protocol Action: 'RADIUS Extensions for IP
> > Port Configuration and Reporting' to Proposed Standard
> > (draft-ietf-radext-
> > for the authors to upload a new revision. We can complete these
> > actions before this has been uploaded, though. I'll contact you
> within
> > a few hours to ask you to review the registries and confirm that
> > everything was completed correctly.
> >
> > thanks,
> > Amanda
> >
> values.
> > > > > "Extended Type" format results in allocation of 255 new
> > > > > Attribute Type values
> > > > of
> say
> > > > - the initial contents of the registry (including a definition
> for
> > > > value 0 and the maximum value)
> > > >

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Tue, 15 Nov 2016 02:12:08 +0000

Dear Authors:

ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED 

We've completed the registry actions for the following RFC-to-be:

draft-ietf-radext-ip-port-radius-ext-16 

ACTION 1:

The IANA Services Operator has added the following entry to the IPFIX Information Elements registry:

Element ID: 458	
Name: sourceTransportPortsLimit
Data Type: unsigned16
Data Type Semantics: totalCounter
Status: current
Description: This Information Element contains the maximum number of IP source transport ports that can be used by an end user when sending IP packets; each user is associated with one or more (source) IPv4 or IPv6 addresses. This IE is particularly useful in address sharing deployments that adhere to REQ-4 of [RFC6888]. Limiting the number of ports assigned to each user ensures fairness among users and mitigates the denial-of-service attack that a user could launch against other users through the address sharing device in order to grab more ports.
Units: ports
Range: 1-65535
Requester: [RFC-ietf-radext-ip-port-radius-ext-16]
Revision: 0
Date: 2016-11-10 

Please see
http://www.iana.org/assignments/ipfix

ACTION 2:

We've added the following entries to the Radius Attribute Types registry:

241.5    IP-Port-Limit-Info    [RFC-ietf-radext-ip-port-radius-ext-16, Section 3.1.1]
241.6    IP-Port-Range    [RFC-ietf-radext-ip-port-radius-ext-16, Section 3.1.2]
241.7    IP-Port-Forwarding-Map    [RFC-ietf-radext-ip-port-radius-ext-16, Section 3.1.3]

Please see
http://www.iana.org/assignments/radius-types

ACTION 3:

We've created the following registry under the "Radius Types" heading:

RADIUS IP Port Configuration and Reporting TLVs
Registration Procedure(s): Standards Action
Reference: [RFC-ietf-radext-ip-port-radius-ext-16]

Value 	Description 	Reference 
0	Reserved	[RFC-ietf-radext-ip-port-radius-ext-16]
1	IP-Port-Type	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.1]
2	IP-Port-Limit	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.2]
3	IP-Port-Ext-IPv4-Addr	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.3]
4	IP-Port-Int-IPv4-Addr	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.4]
5	IP-Port-Int-IPv6-Addr	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.5]
6	IP-Port-Int-Port	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.6]
7	IP-Port-Ext-Port	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.7]
8	IP-Port-Alloc	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.8]
9	IP-Port-Range-Start	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.9]
10	IP-Port-Range-End	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.10]
11	IP-Port-Local-Id	[RFC-ietf-radext-ip-port-radius-ext-16, Section 3.2.11]
12-155	Unassigned

Please see
http://www.iana.org/assignments/radius-types

The updated list of Protocol Registries is available here:
 
http://www.iana.org/protocols/

Please let us know whether the above registry actions have been completed correctly. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's actions are complete. If the document has a team of authors, one reply on behalf of everyone will suffice.

Since you'll be uploading the new version of the document shortly (the new values can be added to that version before you upload), please let us know when this is available to link to.

We'll make any further reference updates in the registries when the RFC Editor notifies us that they've assigned an RFC number.

Best regards,

Amanda Baber

---

From: Dean cheng <[email-masked]>
Date: Tue, 15 Nov 2016 03:12:45 +0000

Hello Amanda,

Thank you for all the three actions taken for the
registry, which I've reviewed and found them correct.

I'll update the draft with the newly assigned
numbers before post the 17.txt and let you know.

Regards
Dean

> Sent: Monday, November 14, 2016 6:12 PM
> Description: This Information Element contains the maximum number of IP
> source transport ports that can be used by an end user when sending IP
> packets; each user is associated with one or more (source) IPv4 or IPv6
> addresses. This IE is particularly useful in address sharing
> deployments that adhere to REQ-4 of [RFC6888]. Limiting the number of
> ports assigned to each user ensures fairness among users and mitigates
> the denial-of-service attack that a user could launch against other
> users through the address sharing device in order to grab more ports.
> Units: ports
> Range: 1-65535
> RADIUS IP Port Configuration and Reporting TLVs Registration
> Procedure(s): Standards Action
> Please let us know whether the above registry actions have been
> completed correctly. As soon as we receive your confirmation, we'll
> notify the RFC Editor that this document's actions are complete. If the
> document has a team of authors, one reply on behalf of everyone will
> suffice.
> 
> Since you'll be uploading the new version of the document shortly (the
> new values can be added to that version before you upload), please let
> us know when this is available to link to.
> 
> We'll make any further reference updates in the registries when the RFC
> Editor notifies us that they've assigned an RFC number.
> 
> Best regards,
> 
> Amanda Baber

---

From: Dean cheng <[email-masked]>
Date: Tue, 15 Nov 2016 03:43:30 +0000

Hi Amanda,

We've just posted the new revision of this draft (17.txt).

Thanks
Dean

> Sent: Monday, November 14, 2016 7:13 PM
> Thank you for all the three actions taken for the registry, which I've
> reviewed and found them correct.
> 
> I'll update the draft with the newly assigned numbers before post the
> 17.txt and let you know.
> 
> Regards
> Dean
> 
> > Description: This Information Element contains the maximum number of
> > IP source transport ports that can be used by an end user when
> sending
> > IP packets; each user is associated with one or more (source) IPv4 or
> > IPv6 addresses. This IE is particularly useful in address sharing
> > 241.7    IP-Port-Forwarding-Map    [RFC-ietf-radext-ip-port-radius-
> ext-
> > 16, Section 3.1.3]
> >
> > Please see
> > notify the RFC Editor that this document's actions are complete. If
> > the document has a team of authors, one reply on behalf of everyone
> > will suffice.
> >
> > We'll make any further reference updates in the registries when the
> > RFC Editor notifies us that they've assigned an RFC number.
> >
> > Best regards,
> >
> > Amanda Baber

Subject: [radext] I-D Action: draft-ietf-radext-ip-port-radius-ext-17.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 15 Nov 2016 03:37:53 +0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions of the IETF.

        Title           : RADIUS Extensions for IP Port Configuration and Reporting
        Authors         : Dean Cheng
                          Jouni Korhonen
                          Mohamed Boucadair
                          Senthil Sivakumar
	Filename        : draft-ietf-radext-ip-port-radius-ext-17.txt
	Pages           : 39
	Date            : 2016-11-14

Abstract:
   This document defines three new RADIUS attributes.  For devices that
   implement IP port ranges, these attributes are used to communicate
   with a RADIUS server in order to configure and report IP transport
   ports, as well as mapping behavior for specific hosts.  This
   mechanism can be used in various deployment scenarios such as
   Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.
   This document defines a mapping between some RADIUS attributes and
   IPFIX Information Element Identifiers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-radext-ip-port-radius-ext/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-ip-port-radius-ext-17

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Tue, 15 Nov 2016 04:49:06 +0000

Hi Dean,

The registries are now pointing to version 17:

I'll tell the RFC Editor we've completed the registry actions. 

thanks again,
Amanda

---

From: Alan DeKok <[email-masked]>
Date: Tue, 15 Nov 2016 08:52:37 -0500

I would like to draw attention to ordering issues between these updates and the RADIUS "data types" document.  The data types document does not include these attributes, but this document has been approved for publication.  And the updates for this document do not contain data types, as required by the new IANA rules in the "data types" document.

  I believe that we can proceed with all updates.  Document ordering is important here.

  Given that this document is further ahead in the publication process, my suggestion is to proceed with this document, and with updating the registries as suggested here.

  Once that's done, I can revise the "data types" document to include data types for these attributes.  At that point, all subsequent allocations from the RADIUS type registry should be paused, and should wait for the "data types" document to be published, and the registry updated.  When that work is finished, the RADIUS type registry can be re-opened for updates, with the caveat that the "data types" requirements now apply.

> On Nov 14, 2016, at 9:12 PM, Amanda Baber via RT <[email-masked]> wrote:

> 241.7    IP-Port-Forwarding-Map    [RFC-ietf-radext-ip-port-radius-ext-16, Section 3.1.3]

  As these attributes are of type TLV, there would normally be sub-attributes listed here.  Instead, we're using a sub-registry.  But that registry isn't referenced in these attributes.

  It would be good to add a cross-reference from these attributes to the new "RADIUS IP Port Configuration and Reporting TLVs".  I'm not sure how that would best be done...

  Alan DeKok.