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

Arran Cudbard-Bell <a.cudbardb@freeradius.org> Fri, 25 July 2014 18:34 UTC

Return-Path: <a.cudbardb@freeradius.org>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6FB241A049F for <radext@ietfa.amsl.com>; Fri, 25 Jul 2014 11:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id t4too6vzo9Ws for <radext@ietfa.amsl.com>; Fri, 25 Jul 2014 11:34:00 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org []) by ietfa.amsl.com (Postfix) with ESMTP id EF6C51A0452 for <radext@ietf.org>; Fri, 25 Jul 2014 11:33:59 -0700 (PDT)
Received: from localhost (localhost []) by power.freeradius.org (Postfix) with ESMTP id 6D1892240333 for <radext@ietf.org>; Fri, 25 Jul 2014 20:33:58 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([]) by localhost (power.freeradius.org []) (amavisd-new, port 10024) with ESMTP id GeK5SK5TuFG1 for <radext@ietf.org>; Fri, 25 Jul 2014 20:33:53 +0200 (CEST)
Received: from [] (unknown []) by power.freeradius.org (Postfix) with ESMTPSA id 63D6D2240168 for <radext@ietf.org>; Fri, 25 Jul 2014 20:33:53 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_77A8BCC1-093D-4B3D-86ED-DCE4DEE59E13"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Pgp-Agent: GPGMail 2.1 (86d0425)
From: Arran Cudbard-Bell <a.cudbardb@freeradius.org>
In-Reply-To: <mailman.0.1406300368.3016.radext@ietf.org>
Date: Fri, 25 Jul 2014 14:33:49 -0400
Message-Id: <D1A82475-4CAA-49D8-A2E3-AC07F4879F15@freeradius.org>
References: <mailman.0.1406300368.3016.radext@ietf.org>
To: radext@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/0TNhRZpSE-B-1XuGRpbf6y2IaHY
Subject: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jul 2014 18:34:02 -0000

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 

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?