Skip to main content

Minutes for RADEXT at IETF-95
minutes-95-radext-2

Meeting Minutes RADIUS EXTensions (radext) WG
Date and time 2016-04-08 15:20
Title Minutes for RADEXT at IETF-95
State Active
Other versions plain text
Last updated 2016-04-11

minutes-95-radext-2
S.Winter started with the usual agenda bashing. Then, he provided the documents
status: The large packet for RADIUS TCP packet
(draft-ietf-radext-bigger-packets-05) passed the IETF LC; no major issues were
raised but a revised document is needed. The data types document
(draft-ietf-radext-datatypes-02) will be sent to the IESG. RADIUS Extensions
for Network-Assisted Multipath TCP (MPTCP) (draft-boucadair-mptcp-radius-01) is
proposed work item (new charter) while other drafts dropped off the radar
(draft-klammorrissette-radext-very-common-vsas and
draft-aravind-radext-message-bundling). See the Chairs’ slides for more details.

M. Boucadair presented the slides for RADIUS Extensions for IP Port
Configuration and Reporting. He recalled that the draft passed the WGLC in
April 2015 and new revisions (07, and 08) were released to address Shepherded
comments received in March 2016. One issue is still pending: Either maintain
the approach in the current version of the draft that is, as the three
attributes defined in the draft carry similar data, the TLVs have the same name
and number, when encapsulated in any one of the three parent attributes, or
follow the Lionel’s proposed alternate approach that is, define registries for
each nested attribute (a TLV have a number that depends on its parent
attribute). M. Boucadair recalled that a need is to be made clear for future
specifications. It was agreed to maintain the current IANA assignment approach
and proceed with the document publication process.

A. DeKok went through his slides (CoA Proxying). (The quality of the audio is
not that good). He clarified first the open issues (e.g., proxy spoofing is
always possible, mandatory attributes need to be removed before being sent to
the NAS). He suggested two text proposals for the removal of mandatory
attributes. S. Winter indicated that the wording of the second proposal needs
to be clarified, especially what is meant by (all “server”). Jim wasn’t
comfortable with the second proposal. Alan will use the first and explain why
it is necessarily. Alan suggested a wording in the mailing list.

S. Winter presented the cooperation population draft (he went through the
slides). Several comments were raised in the mailing list recently. S. Winter
provided an update since the WG adoption: e.g., introduce a terminology
section, maintain the same advice, etc. Then, he went through the list of
discussion points raised in the mailing list (refer to the slides). He
suggested following the NAI wording for the point about normalisation: “EAP
peer may normalise before he will put that in the document. As per the point
about all EAP methods, Lionel raised a case that is supported at the 3GPP (but
he needs to further check) and suggested to maintain the text in the draft
because the use case is relevant. Also, Lionel asked if B. Adoba agreed with
the proposed resolution.

M. Boucadair went through his slides on “RADIUS Extensions for Network-Assisted
Multipath TCP”. The deployment model targets aggregating the resources
associated with multiple network attachments managed by the same network
provider. MPTCP features are enabled in the CPE while dedicated functions
(called MPTCP Concentrators) are enabled at the network side. Authorized CPEs
are provisioned with one or a list of MPTCP concentrators; each identified by
one or multiple IP addresses. This deployment model leverages on network
authorisation procedures (RADIUS-based). The proposed attributes follow the
recommendation in I-D.ietf-radext-datatypes and RFC6158. The draft was already
reviewed by A. DeKok. Several questions were raised by L. Morand and S. Winter
about MPTCP and the role of the CPE. M. Boucadair clarified that the CPE is not
aware about the RADIUS; RADIUS exchange occurs between the NAS and the AAA
server when the CPE attaches the network. If the CPE is authorized to make use
of MPTCP Concentrators’ resources, a list of MPTCP-Concentrator-IPvx attributes
will be returned to the NAS that will pass their content to the DHCP server
will use their content to reply to a requesting CPE. M. Boucadair asked for
considering adding a charter work item for this draft. L. Morand will review
the draft.