Subject: Re: [radext] Adoption of draft-cheng-radext-ip-port-radius-ext-00.txt ?

From: Stefan Winter <[email-masked]>
Date: Fri, 02 May 2014 16:57:36 +0200

Hello all,

> The call for adoption ends 7 May 2014.

That day is not long from now, and there was only one single opinion on
the list.

Could all please consider looking at the document, and let us know your
view on this?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Dean cheng <[email-masked]>
Date: Sat, 3 May 2014 01:09:11 +0000

As a co-author, I support the adoption.

Also, thanks Alan for his comments that we'll incorporate
in the next revision.

Dean

> -----Original Message-----
> From: radext [mailto:[email-masked]] On Behalf Of Stefan
> Winter
> Sent: Wednesday, April 23, 2014 5:47 AM
> To: [email-masked]
> Subject: [radext] Adoption of draft-cheng-radext-ip-port-radius-ext-
> 00.txt ?
> 
> Hello,
> 
> as discussed recently, we believe radext is at a point where old items
> are finished and new work can be added to our workload.
> 
> There was a good and positive discussion on what is now draft-cheng-
> radext-ip-port-radius-ext-00.txt in the London meeting.
> 
> BEHAVE (where this work could fit into) is not taking on new work. The
> RADEXT charter already allows us to work on RADIUS extensions, so if
> there is support for adoption of this work here in our WG, we can take
> it on pretty much immediately.
> 
> So, this work needs a home and we could be that home if we want to.
> 
> This mail starts a two week call for adoption for this draft. Please
> reply to this mail indicating whether you are in favour for adoption or
> not. Since the discussions in London were of generic nature, and not
> directly asking for adoption, there is no default - silence does not
> count as acceptance. So don't be silent :-)
> 
> de la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: +352 424409 1
> Fax: +352 422473
>

---

From: Peter Deacon <[email-masked]>
Date: Sun, 4 May 2014 00:21:53 -0700 (Pacific Daylight Time)

> There was a good and positive discussion on what is now
> draft-cheng-radext-ip-port-radius-ext-00.txt in the London meeting.

> count as acceptance. So don't be silent :-)

We are interested in the feature set and support adoption.  Have a number 
of comments and questions about this draft.

1. Is section 5 table correct where a maximum of one instance of each 
container is allowed?

There may be value in more than one to for example set IP-Port-Limit to 
configure independently per IP layer protocol or to allocate ports across 
multiple external addresses.  If really limited to just one the TLV 
grouping can be collapsed into normal attributes.

If multiple instances allowed during CoA for IP-Port-Range care 
may be needed to avoid ambiguities synchronizing change.
-- 

2. Recommend throughout draft having one attribute/TLV per data field 
replacing all instances where multiple fields are defined in 
any custom fixed formats.
--

3. Confused by definition of IP-Port-Type 3.1 Extended-Type seems to be 
allocating an attribute Id for each IP protocol.  Recommend defining an 
attribute IP-Port-Type using value field of attribute to determine IP 
layer protocol(s) to be associated.

Using IP-Port-Type as a container is problematic the way RFC6929 works 
attributes within each container are defined separately .. there is no pool 
of global attributes able to be reused short of very redundant 
redefinition.
--

4. Usage contradiction

Section 1
"IP-Port-Range:This attribute may be carried in RADIUS Access-
       Accept, Accounting-Request or CoA-Request packet. "

Section 3.3
"  The IP-Port-Range MAY appear in an Accounting-Request packet.
    The IP-Port-Range MUST NOT appear in any other RADIUS packets."

Section 5.
0       0      0      0         0-1        TBA IP-Port-Range

Prefer option of having port ranges be configurable via Access-Accept/CoA.
-- 

5. Have had requests to have ability to configure NAT session limits. 
For example IP-NAT-Session-Limit (Proto=TCP,Limit=10000) limits session to 
10000 concurrent TCP associations in NAT state table.

This is essentially IP-Port-Limit except quantity of associations rather 
than ports... noting port limits do not translate to session limits as 
ports are per destination address.
--

6. Comments on internal and external addresses.

IP-Port-Limit - Extended-Type (container)
 	- IP Protocol (TCP,UDP,ICMP,TCP+UDP,TCP+UDP+ICMP,...) - TLV
 	- Limit - TLV

IP-Port-Range - Extended-Type (container)
 	- IP Protocol - TLV
 	- Range Start - TLV
 	- Range End - TLV
 	- External IP - TLV

IP-Port-Forwarding-Map - Extended-Type (container)
 	- IP Protocol - TLV
 	- Internal Port - TLV
 	- External Port - TLV
 	- Internal IP - TLV

With regards to IP-Port-Limit and IP-Port-Range on Access-Accept there 
should be parity in terms of opportunity to specify external address.

IP-Port-Forwarding-Map would be helpful to include External IP such that 
external face of services mapped internally are configurable 
independently.  (e.g. Customer wants to run a web site on port 80 on 
specific external IP)

regards,
Peter

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 06 May 2014 12:23:22 +0300

As n co-author I am in favor taking this I-D as a basis for the WG 
engineered solution.

- Jouni

4/23/2014 3:47 PM, Stefan Winter kirjoitti:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 09 May 2014 09:07:04 -0500

Hi Stefan,

Not that much replies on the mailing list, but my own meeting minutes 
tell me:

Who     read this draft: 5

Who     is interested in this work: 8

So it seems like a good one to adopt.

Regards, Benoit

---

From: Stefan Winter <[email-masked]>
Date: Fri, 09 May 2014 16:25:21 +0200

Hello,

> The call for adoption ends 7 May 2014.

The 7th of May is now history in all timezones on the planet, so the
call for adoption is now closed.

Of all the four people that responded (2 of which were co-authors), all
were in favour of adoption; plus more support in the room, as Benoit's
mail clarifies. This looks like unanimous support for adoption of the
document!

This document will now become a chartered work item.

Authors, please re-submit this document as
draft-ietf-radext-ip-port-radius-ext-00.

From the comments during the adoption call, I understand that there is
still plenty to discuss and refine. I will tentatively reserve 10
minutes on the IETF90 agenda on that topic.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473