Subject: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback

From: Arran Cudbard-Bell <[email-masked]>
Date: Fri, 25 Jul 2014 14:33:49 -0400

Following up from the meeting at IETF90

SCTP/UDP encapsulation
----------------------
RFC6951 does allow SCTP to be encapsulated by UDP packets.
The reasons stated in the RFC are for legacy NAT traversal, and to allow SCTP to be
implemented on hosts which do not allow direct access to the IP layer.

When tunnelling SCTP UDP/9899 is used, though this is not a requirement, and the RFC states 
that other ports can be used.

Do people feel that it would be useful to be able to represent tunnelling with the attributes 
of cgn-cfg?

Protocol enumeration
--------------------
Majority of NAT'd communications will likely be TCP/UDP ICMP, but there is no reason why 
SCTP and other more exotic protocols couldn't be NAT'd.

To support arbitrary protocols, the extended IP-Port-Type attribute could reference the 
IANA protocol numbers registry, with the caveat that the protocol referenced used ports 
as connection identifiers.

Multiple IP-Port-Type attributes could be included to represent a port mapping in multiple 
protocols (where enum values 1 and 2 are used currently).

Explicit references to TCP/UDP/ICMP other than where used as examples would then be removed.

Reporting for dynamic CGN sessions (PCP)
----------------------------------------
ISPs are looking at NAT44 as a stopgap measure until v6 connectivity is sufficient to
run v6 only on CPEs.

UPnP to PCP gateways on the CPE allow legacy applications to work, by requesting specific
public ports on the NAT44 device.

Reporting for all N to 1 mappings required when used by ISPs for compliance reasons 
(in the UK at least). Law enforcement needs to be able to map Public IP/Port to private
IP and subscriber.

Just to check, in these cases would IP-Port-Forwarding-Map would be used to report these 
mappings, in a similar way as to how IP-Port-Range is used in Section 4.1.2?

Clarification around IP Port Allocation/De-allocation
-----------------------------------------------------
Section 4.1.2 describes a method of reporting range allocation and range deallocation but 
does not describe how to differentiate between the two.

Making an inference from other parts of the document, it seems that each Accounting-Request
packet records information about a single IP-Port-Range or IP-Port-Forwarding-Map 
allocation/deallocation.

Are separate RADIUS accounting sessions then, generated for each IP-Port-Range or 
IP-Port-Forwarding-Map? Should these sessions be linked to the subscriber's BNG session 
with Acct-Multi-Session-Id?

Or alternatively are each of the Accounting-Requests just Interim-Updates, and if so how
do we know when a port allocation is being reported as opposed to deallocation?

-Arran

---

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Jul 2014 14:47:36 -0400

After some other discussion with Arran, I think there is another way
to solve this problem.

  As background, this document allows for a NAS to communicate a TCP/UDP
port set information for specific hosts.  It seems duplicate effort to
re-define all of the port / protocol information in a RADIUS document.
These information elements are already defined in IPFIX:

http://www.iana.org/assignments/ipfix/ipfix.xhtml

  Port ranges, protocols, etc. are all there.

  I wrote a document for IPFIX to RADIUS mappings:

http://tools.ietf.org/html/draft-dekok-radius-ipfix-00

  The intent was to allow for flow-specific accounting in RADIUS.  That
goal was talked about a lot 2-3 years ago, but has since been ignored.
I believe that we can re-use it here.

  The only change necessary to my IPFix document is to add the following:

- use of Acct-Multi-Session-Id to have flow-specific accounting streams

- use Acct-Multi-Session-Id and Acct-Status-Type start / stop to
indicate port range allocate / de-allocate.

  The benefits here are numerous, I think.  RADIUS gains flow-specific
accounting, and port range allocation signaling.  However, RADIUS does
*not* need to manage any attributes related to ports, protocols, ranges,
etc.  All of that is already defined in IPFIX.  We could just reference
IPFIX, and be done.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 25 Jul 2014 15:04:11 -0400

Is this in accounting document, an authorization document or both?

---

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Jul 2014 15:16:18 -0400

> Is this in accounting document, an authorization document or both?

  Right now, the IPFix document is both.  It provides ways for the
RADIUS server to request accounting on specific flows.  And for the NAS
to send accounting for those flows.

  The "behave" document is accounting only.  The NAS pro-actively
informs the RADIUS server that it has allocated ports to a user.

  I believe that the two uses can be supported by the IPFix document,
with minimal changes to it.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Jul 2014 15:23:56 -0400

And reviewing the document some more:

- it doesn't use TLVs.  It uses the 6929 attribute format.  But it still
packs multiple fields into one attribute.  Each field needs to be a
separate sub-TLV.

  e.g.  Section 3.1:

     This attribute is of type complex [RFC6158] ..

  There is no need for a "complex" type.

- ST (Session Type)

  This field defines identifiers for TCP, UDP, and ICMP.  We already
have identifiers defined in IPv6.  This document should re-use those
values, as it avoids the need for us to have more RADIUS-specific
allocations.

  It could instead refer to the IPv6 protocol mappings, define "ST" as a
TLV, and then say "if this rule applies to TCP and UDP, then list both
TCP and UDP as protocols".

  Alan DeKok.

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 26 Jul 2014 03:49:14 +0300

Just for my clarification, we did not handle 
draft-cheng-behave-cgn-cfg-radius-ext during the meeting, thus which 
document is meant here then? I assume 
draft-ietf-radext-ip-port-radius-ext is meant here, right.

- Jouni

7/25/2014 9:33 PM, Arran Cudbard-Bell kirjoitti:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 25 Jul 2014 21:52:12 -0400

Yes. I'll double check the document contents.  But the general idea was correct, I think. 

> On Jul 25, 2014, at 8:49 PM, Jouni Korhonen <[email-masked]> wrote:
> 
> 
> Just for my clarification, we did not handle draft-cheng-behave-cgn-cfg-radius-ext during the meeting, thus which document is meant here then? I assume draft-ietf-radext-ip-port-radius-ext is meant here, right.
> 
> - Jouni
>

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Sat, 26 Jul 2014 09:01:44 -0400

>> Just for my clarification, we did not handle draft-cheng-behave-cgn-cfg-radius-ext during the meeting, thus which document is meant here then? I assume draft-ietf-radext-ip-port-radius-ext is mean…

draft-ietf-radext-ip-port-radius-ext-01 appears to be a retitled version of draft-cheng-behave-cgn-cfg-radius-ext with some updates.

My points all still apply to draft-cheng-behave-cgn-cfg-radius-ext.

Alan's point about IPFIX still applies. 

draft-cheng-behave-cgn-cfg-radius-ext does now use Sub-TLVs.

The bulk of the document is the same.

I guess there's no meta data added to drafts when they're republished under a different title?

-Arran

Arran Cudbard-Bell <[email-masked]>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Sat, 26 Jul 2014 09:02:31 -0400

> My points all still apply to draft-cheng-behave-cgn-cfg-radius-ext.

make that draft-ietf-radext-ip-port-radius-ext

> draft-cheng-behave-cgn-cfg-radius-ext does now use Sub-TLVs.

and draft-ietf-radext-ip-port-radius-ext.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 26 Jul 2014 09:03:29 -0400

>   Yes. I'll double check the document contents.  But the general idea was correct, I think. 

  I've checked the documents again.  The document
draft-ietf-radext-ip-port-radius-ext uses good design for the TLVs, etc.

  My previous comments about IPFix still apply, though.  I think that
the ip-port document could leverage the IPFix document.  That way the
ip-port document would contain *no* new attribute definitions.  Instead,
it would explain how to use the RADIUS/IPFix attributes.

  Alan DeKok.

---

From: Arran Cudbard-Bell <[email-masked]>
Date: Sat, 26 Jul 2014 09:12:37 -0400

> Is this in accounting document, an authorization document or both?

Both. It defines attributes that can be included in an Access-Accept
or CoA-Request to configure explicit port ranges or mappings for a
subscriber's NAT session.

It also states that those attributes can be used for reporting purposes
in Accounting-Requests, when a NAT device allocates an additional IP
port range, to a subscriber but doesn't go into any more detail than 
that.

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 29 Jul 2014 11:35:00 +0300

> I guess there's no meta data added to drafts when they're republished under a different title?

Nope.. drafts are quite free terrotiry to do whatever folks want ;)

- Jouni

---

From: Dean cheng <[email-masked]>
Date: Tue, 29 Jul 2014 18:23:24 +0000

Alan, Arran,

Thanks for the suggestions, I'll take a look
of these and get back to you.

Please note that this draft is now
draft-ietf-radext-ip-port-radius-ext-01 that
was discussed last week in Toronto.

Dean

> -----Original Message-----
> From: radext [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Friday, July 25, 2014 11:48 AM
> To: Arran Cudbard-Bell
> Cc: [email-masked]
> Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback
> 
>   As background, this document allows for a NAS to communicate a
> TCP/UDP port set information for specific hosts.  It seems duplicate
> effort to re-define all of the port / protocol information in a RADIUS
> document.