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

[Peter Deacon <[e-mail]>]

On Wed, 23 Apr 2014, Stefan Winter wrote:

> 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.

> 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 :-)

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