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

Alan DeKok <aland@deployingradius.com> Sat, 26 July 2014 01:52 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29651A0084 for <radext@ietfa.amsl.com>; Fri, 25 Jul 2014 18:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI-bmiqxWA0c for <radext@ietfa.amsl.com>; Fri, 25 Jul 2014 18:52:20 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E93DB1A007E for <radext@ietf.org>; Fri, 25 Jul 2014 18:52:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 15A4B2240333; Sat, 26 Jul 2014 03:52:17 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKrS4Y7QPQ6N; Sat, 26 Jul 2014 03:52:13 +0200 (CEST)
Received: from [100.86.11.210] (unknown [207.164.79.82]) by power.freeradius.org (Postfix) with ESMTPSA id E71E62240168; Sat, 26 Jul 2014 03:52:12 +0200 (CEST)
References: <mailman.0.1406300368.3016.radext@ietf.org> <D1A82475-4CAA-49D8-A2E3-AC07F4879F15@freeradius.org> <53D2FB0A.1050002@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <53D2FB0A.1050002@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <2254D673-36FF-4B64-AC0C-A7AC9CE4991A@deployingradius.com>
X-Mailer: iPhone Mail (11D257)
From: Alan DeKok <aland@deployingradius.com>
Date: Fri, 25 Jul 2014 21:52:12 -0400
To: Jouni Korhonen <jouni.nospam@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/iQiCl7ceZiX2h_WAufcq8SZaOps
Cc: "radext@ietf.org" <radext@ietf.org>, Arran Cudbard-Bell <a.cudbardb@freeradius.org>
Subject: Re: [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: Sat, 26 Jul 2014 01:52:24 -0000

  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 <jouni.nospam@gmail.com> 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
> 
> 7/25/2014 9:33 PM, Arran Cudbard-Bell kirjoitti:
>> 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
>> 
>> 
>> 
>> 
>> _______________________________________________
>> radext mailing list
>> radext@ietf.org
>> https://www.ietf.org/mailman/listinfo/radext
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext