Subject: Re: [Softwires] WGLC on draft-ietf-softwire-map-radius-14 - 2 of 2

From: [email-masked]
Date: Fri, 6 Apr 2018 16:59:05 +0200

Hi,

Review part 2.

Cheers,
Ian

-----
4. Attributes 
4.a) 'sub options' is used. Conventionally, this is
hypenated as 'sub-options'. Please change throughout.

4.b) It would be more accurate to say:
Different combinations of sub-options are
   required for each type of S46 Container...

4.c)
"  The RADIUS attribute
   for Dual-Stack Lite [RFC6333] is defined in [RFC6519]."

This is the first time in the document that DSLite is referenced.
Would it be better to put a paragraph in the Introduction saying
that this document is not concerned with DSLite/RADIUS as it's 
already covered in RFC6519.

4.c)
The S46 Container Options section describes how the containers and
options are constructed. It would read better to have this overview text
before descrbing the structure of any of the attributes/options.

4.e)
In the description text around Fig.2 a pointer to the table in 4.7
would be helpful. It may actually be better to move the table from
section 4.7 into section 4.2 so they can be compared directly by
the reader.

4.f)
Figure 2 doesn't really make it clear that the relevant (and necessary)
sub-options (numbered 1-5) is decided by which on of the three
S46 container options is being used. This makes it confusing to understand.

As a suggestion, would 3 diagrams (one for each type) structured like this
be more clear showing what is necessary and what is optional?

                       / (Mandatory)            /1.Rule-IPv6-Prefix
                      |                        |   sub-option
                      | 1.S46-Rule ------------+ 2.Rule-IPv4-Prefix
                      |    sub-option          |   sub-option
                      |                        | 3.EA Length
 S46 MAP-E Container--+                         \  sub-option
  Option              | 2.S46-BR Sub Option
                - - - - - - - - - - - - - - - - - - - - - - - - - 
                      | (Optional)               /1.PSID-offset
                      |                         |   sub-option
                      | 3.S46-PORTPARAMS -------+ 2.PSID-len
                      |     sub-option          |   sub-option
                      |                         | 3.PSID
                       \                         \  sub-option

The paragraph begining 'There are three types of S46 Container Options...'
would need to be moved before this for readability.

4.g)
The paragraph begining 'There are three types of S46-Rule Sub Options...'
seems to be in the wrong section. It belongs in 4.3.1.

4.h)
s/The S46-BR Sub Option can only be encapsulated in the MAP-E Container
   Option or the Lightweight 4over6 Container Option./
   The S46-BR Sub Option can only be encapsulated in the MAP-E or 
   Lightweight 4over6 Container Options./

4.i)
4.3.3.  S46-DMR Sub Option
s/set to all zero./set to all zeros./

4.j)
4.3.4. S46-V4V6Bind Sub Option 
s/There MUST be at most one/There MUST be exactly one/

4.k)
4.3.5.  S46-PORTPARAMS Sub Option
Suggest that the first sentance is extended to say:
The S46-PORTPARAMS Sub Option specifies optional port set information
   that MAY be provisioned to CEs to configure sharing of an IPv4 address.

4.l)
Throughout this section, it would be a good idea to put in a pointer
to the section of RFC7598 that the option/sub-option corresponds to.

4.m)
s/The Softwire46-Multicast attribute conveys the IPv6 prefixes to be
   used in [RFC8114] to synthesize IPv4-embedded IPv6 addresses./
   The Softwire46-Multicast attribute conveys the IPv6 prefixes to be
   used to synthesize IPv4-embedded IPv6 addresses as per [RFC8114]./

4.n)
This attribute MAY be used in Access-Request packets as a hint to the
   RADIUS server.  For example, if the BNG is pre-configured with
   Softwire46-Multicast, these prefixes MAY be inserted in the
   attribute.

Is this saying that the attribute could be pre-configured with a
value in the BNG's AAA client meaning that it wouldn't be requested from
AAA, but would be supplied in the DHCP message? Please can you expand
the description. I also wonder if this statement is true for any of
the other attributes described in the document.

4.o)
The definitions of which RADIUS messages types the multicast 
attribute can appear in should also exist for the unicast and priority
attributes.
Update - having read section 4.10, the information is there, but
is duplicated for multicast. One common format for the information
and pointers would be cleaner.

4.p)
The description text and formatting between the 4.2-4.8 options is
inconsistent and should be aligned. Personally, I think the bullet
point list of what is and isn't permitted in section 4.9 is clear
and could be usefully used in 4.2-4.9.

4.q)
4.9.1.  ASM-Prefix64 TLV
The field in the diagram is called 'Prefix-Length', but in the
description, this field is 'Length'. This also needs fixing
in 4.9.2 and 4.9.3

4.r)
4.9.2 & 4.9.3
s/This fiel is reserved./This field is reserved./

4.s)
Section 4.9 uses TBD1 as a placeholder for an IANA assignment. TBD1-3
are already used earlier in the document.

---------

6. IANA Considerations
6.a)
"This document requires the assignment of two new RADIUS Attribute..."
there is then a list of 3 new attributes.

6.b)
6.1.  S46 Mechanisms and Their Identifying Option Codes
It seems that there is a requirement here for the BNG AAA client/DHCPv6
server to provide a translation between the RADIUS option code in 
the newly requested registry and the RFC8026 option 111 values (which
will be sent to the DHCPv6 client) listed in the "Option Codes Permitted in
the S46 Priority Option" IANA registry.
This process isn't described at the moment, and I wonder if this is really
the right way to solve the problem. Is this something that you have
considered?

------------
7.  Security Considerations
7.a)
"  A malicious user may use MAC address spoofing on the shared password
   that has been preconfigured on the DHCPv6 server to get unauthorized
   configuration information."

I'm not sure I understand the nature of this attack. Is it really the 
DHCPv6 server that you mean here, or the BNG (specifically the AAA
client function)? Is there a reference to where this attack is described
in greater deatail.

7.b)
RFCs 7599 and 8114 should also be listed.

I-D Nits output

idnits 2.15.01 

tmp/draft-ietf-softwire-map-radius-15.txt:
   Attempted to download rfc5822 state...
   Failure fetching the file, proceeding without it.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (March 21, 2018) is 16 days in the past.  Is this
     intentional?

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Obsolete informational reference (is this intentional?): RFC 5226
     (Obsoleted by RFC 8126)

     Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------

> On 26. Mar 2018, at 15:43, Yong Cui <[email-masked]> wrote:
> 
> Hi folks,
> 
> The authors of draft-ietf-softwire-map-radius-14 believe this document is ready for advancement.
> We would like to issue a working group last call starting from today to April 9th.
> 
> Please send your substantial comments to the list during the last call. You are also welcome to send your editorial comments directly to the authors.
> 
> Thanks for reviewing the draft.
> 
> 
> Yong Cui and Ian Farrer
> 
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: [email-masked]
Date: Fri, 6 Apr 2018 16:58:58 +0200

Hi,

Here’s my review of the draft. It’s rather long so I’ve had to submit it as two emails. It’s based on -15. 

Cheers,
Ian

Title
T.a)
 RADIUS Attribute for Softwire Address plus Port based Mechanisms

 To improve readability and as this defines 3 new RADIUS attributes, 
 'RADIUS Attributes for Address plus Port based Softwire Mechanisms'

---------
Abstract:
A.a)
"IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6
   connectivity services simultaneously during the IPv4/IPv6 co-existing
   period." 

This isn't really true. The transisition mechanisms don't provide
v6 connectivty, they rely on this being there and working. Suggested re-word:

IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6
   connectivity services simultaneously during the IPv4/IPv6 co-existence
   period.
   
A.b)
"The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   options have been defined to configure Customer Edge (CE) in MAP-E,
   MAP-T, Lightweight 4over6 and PREFIX64 option for Multicast Basic
   Bridging BroadBand (mB4) in multicast scenarios. "
   
Suggested re-word for readability: 
   DHCPv6 options have been defined for configuring clients to use MAP-E,
   MAP-T, Lightweight 4over6 and Multicast Basic Bridging BroadBand (mB4) in multicast scenarios.  

A.c)
The abstract has both the expanded and abbrieviated form of a few terms
(e.g. BNG). These definitions are also repeated later in the introduction.
As these terms are defined in the IETF acronyms list
https://www.rfc-editor.org/materials/abbrev.expansion.txt <https://www.rfc-editor.org/materials/abbrev.expansion.txt>
there's no need to provide these definitions, just the acronyms would
be OK. 
As a suggestion for readability - DHCPv6, RADIUS, AAA, and BNG are well
known so don't need the expanded form. mB4 is less well known, so
the expanded version is more helpful.
The repetitions of the definitions in the Introduction can be removed.

A.d)
"This document defines two new Remote Authentication Dial In User
   Service (RADIUS) attributes that carry CE or mB4 configuration
   information from an AAA server to BNG."

There's actually 3 new attributes in the draft (Softwire46-Priority
is missing).

------

1. Introduction
1.a)
It would simplify the overall readibility of the document
to define the MAP-E, MAP-T and lw4o6 (i.e. RFC7598 configured)
softwires as 'unicast' and the RFC8114 as multicast in the 
Intro. This would avoid the need to list MAP-E, MAP-T...
etc. throughout.

1.b)
s/Recently providers/Recently, providers/

1.c)
s/started to deploy IPv6 and consider how to transit to IPv6./
started deployment and transition to IPv6./

1.d)
"In particualr, the CE uses DHCPv6 options to discover the
   Border Relay (BR) and retrieve Softwire46 (S46) configurations."

This is one way that configuration can be done - there's also
a YANG model in development and DHCPv4o6 provisioning. It would be
more accurate to say:

"[RFC7598] defines DHCPv6 options for provisioning
CEs for unicast softwires."

1.e)
For the mutlicast section, all of the fields that are present
in OPTION_V6_PREFIX64 are described in full, but this is not
done for the unicast equivalents. It would make sense to be
uniform between the two, but if all of the options/sub-options
from RFC7598 get included, then it's going to get pretty long.

I think it would improve the consistency and readability
without brining in large amounts of duplication to remove
the text starting 'The following lists the multicast-related
information...' upto (and including) the Unicast Prefix64
description.

In it's place, a paragraph describing the relationship between
this document and RFC7598/8115 could be added, referencing the
relevant sections in those RFCs that the fields are defined.

1.f)
After the sentence "A DHCPv6 server function is
   assumed to be embedded in the BNG that allows it to locally handle 
   any DHCPv6 requests initiated by hosts." it would be
   worth adding that the term BNG is used througout the document
   to describe a device which functions as both the AAA client
   and DHCPv6 server. 

1.g)
s/MAP-E[RFC7597], MAP-T[RFC7599] and Lightweight 4over6[RFC7596]/
MAP-E [RFC7597], MAP-T [RFC7599] and Lightweight 4over6 [RFC7596]/

1.h)
s/options[RFC7598]/options [RFC7598]/

1.i)
Last paragraph: It would also be worth saying how the structure of the 
DHCP options and field namings are preserved so they can 
easily be mapped between DHCP and RADIUS.

----------------------------

3. Configuration Process with RADIUS
3.a)
s/CE with MAP/CE with softwire/

3.b)
s/how the RADIUS protocol and DHCPv6 co-operate/how the RADIUS and
DHCPv6 protocols co-operate/

3.c)
The figure is easier to follow if it is space out a bit more and 
clafifies the first step:

  CE                             BNG                         AAA Server
  |                               |                               |
  |-------1.DHCPv6 Solicit------->|                               |
  |(ORO with unicast and/or m'cast|                               |
  |    container option code(s))  |                               |
  |                               |                               |
  |                               |-------2.Access-Request------->|
  |                               | (S46-Configuration attribute  |
  |                               |and/or S46-Multicast attribute)|
  |                               |                               |
  |                               |<------3.Access-Accept---------|
  |                               | (S46-Configuration attribute  |
  |                               |and/or S46-Multicast attribute)|
  |                               |                               |
  |<----4.DHCPv6 Advertisement----|                               |
  |     (container option(s))     |                               |
  |                               |                               |
  |-------5.DHCPv6  Request------>|                               |
  |     (container Option(s))     |                               |
  |                               |                               |
  |<--------6.DHCPv6 Reply--------|                               |
  |     (container option(s))     |                               |
  |                               |                               |
               DHCPv6                         RADIUS

3.d)
s/1.  First, the CE may initiate a DHCPv6 Solicit/For unicast,
the CE initiates a DHCPv6 Solicit/

3.e)
Citing the relevant RFC number after every term makes it more
difficult to read. As these are already referenced earlier in the
document, they don't need to be repeated here.

3.f)
Replace:
 For the multicast case, OPTION_V6_PREFIX64 should be included for the delivery of multicast
   services in the context of transition to IPv6.
with:
 For the multicast case, the the option number for OPTION_V6_PREFIX64 (113)
 should be included in the client's ORO.

3.g)
"Note however, that the ORO (Option Request option) with the S46
Container option code
   could be optional if the network was planned to be S46-enabled by
   default."

As this is a RADIUS specification, this sentance can be removed.

3.h)
s/it should initiate/it initiates/

3.i)
s/radius/RADIUS/ - This needs to be done throughout the document.

3.j)
s/a User-Name attribute (1) should be filled by a CE MAC address or interface-id or
   both. This message will be sent to the RADIUS server./a User-Name attribute (1)
   is completed with either a CE MAC address, interface-id or
   both and sent to the RADIUS server./

3.k)
This paragraph is a little hard to follow:
   2.  When the BNG receives the Solicit message, it should initiate a
   radius Access-Request message.  In this message, a User-Name
   attribute (1) should be filled by a CE MAC address or interface-id or
   both.  This message will be sent to the RADIUS server.  In this
   message, a User-password attribute (2) should be filled by the shared
   password that has been preconfigured on the DHCPv6 server, requesting
   authentication as defined in [RFC2865] with the corresponding
   Softwire46-Configuration Attribute or Softwire46-Multicast Attribute.
   The Softwire46-Configuration Attribute and Softwire46-Multicast
   Attribute will be defined in the next Section.

Suggested re-word (also are all of teh attributes necessary? Are 
any optional?)

2, When the BNG receives the Solicit message, it should initiate a
RADIUS Access-Request message continaing: A User-Name attribute (1)
(with either a CE MAC address, interface-id or both), a User-password
attribute (2) (with a pre-configured shared password as defined in
[RFC2865]), and the Softwire46-Configuration Attribute and/or
Softwire46-Multicast Attribute (as reuquested by the client).
The resulting message is sent to the RADIUS server.

3.l)
Item 3. uses an RFC2119 MUST statement. This is the first time
in the message flow that any compulsory behaviour is defined. The
requirements language should be consitent throughout all of the steps
(either all RFC2119, or none)

A MUST here is also strange. What if the AAA server doesn't have
the requested configuration to supply to the client?

3.m)
In the DHCPv6 Advertisement message, there needs to be the
corresponding DHCPv6 option holding the correct information
from the RADIUS message. This means that we need to map the 
fields from the attributes to the options. A table showing
how this mapping is done would be very useful.

3.n)
Suggested re-word:
old:
5. After receiving the Advertise message, the CE MAY request for the
   corresponding S46 Container Option, by including the S46 Container
   option in the Request message.

new:
5. On receipt of an Advertise message containing one or more of the requested DHCPv6
softwire container options (94, 95, 96, or 113) the CE MAY request configuration
for the desired softwire mechanism(s) by including the option code(s) in the ORO
of the DHCPv6 Request message.

3.o)
Suggested re-word:
old:
6.  After receiving the client's Request message, containing the
corresponding S46 Container option, the BNG SHOULD reply to the CE
with the message containing the S46 Container option. 
new:
6.  When the BNG receives the client's DHCPv6 Request message, it
constructs a Reply message containing the softwire
container options enumerated in the ORO.

3.p)
"The recommended format of the MAC address is defined as Calling-Station-
Id (Section 3.20 in [RFC3580] without the SSID (Service Set
Identifier) portion."

I don't understand the meaning of this sentence in context of where we
are in the message flow. What is the MAC address that is needed at 
this stage?

3.q)
Suggested re-word:
   For Lightweight 4over6 [RFC7596], the subscriber's binding state
   should be synchronized between the AAA server and lwAFTR.  If the
   bindings are pre-configured statically in both the AAA server and
   lwAFTR, an AAA server does not need to configure the lwAFTR anymore.
   Otherwise, if the bindings are locally created on-demand in an AAA
   server, it should inform the lwAFTR with the subscriber's binding
   state, in order to synchronize the binding information of the lwB4
   with the lwAFTR.

with:
   For Lightweight 4over6 [RFC7596], the subscriber's binding state
   needs to be synchronized between the clients and the lwAFTR. 
   This can be achieved in two ways: pre-configuring the 
   bindings statically on both the AAA server and lwAFTR, or on-demand
   whereby the AAA server updates the lwAFTR with the subscriber's binding
   state as it is created or deleted.

3.r)
The paragraph begining "The authorization process could also..." doesn't
really make sense where it is located. The previous paragraph does
not follow from the previous para. concerning lw4o6 syncronisation and
refers to a previous scenario, although it's not really clear what
that scenario is.
This could be cleared up by (1) making it clear that section 3 fig 1.
is describing combined Authentication and Authorisation. (2) Creating
a sub-section for this paragraph (and the one below it) that detail
what the changes are from the steps in section 3 (i.e. where additional
attributes are needed / not needed and what they contain).

3.s)
The final 3 paragraphs deal with some error handling conditions. Perhaps
a sub-section for these would make for a better structure?

3.t)
What happens if steps 1-4 complete, but the BNG never receives a
request message from the client? In this case, the AAA has allocated
resources, but they are not actually in use. Is there a way that
the BNG can invalidate the request after a timeout, or is there
another error handling mechanism that should be used?

3.u)
There's no text on what happens when the client send a DHCPv6 Release,
Decline, or an associtated DHCPv6 lease expires (invalidating any
options supplied with that lease).

3.v)
As this section is describing how the different attrributes are
requested and used, it would be worth also having a sub-section
concerned with the interaction of Softwire46-Priority Attribute
and RFC8026.

---

From: Sheng Jiang <[email-masked]>
Date: Sun, 8 Apr 2018 08:51:26 +0000

As a co-author, I do think this document is a real useful one. The authors have put a quite lot affords to make it into a good sharp. Consequently, I am in favor of advancing this document.

Sheng

> -----Original Message-----
> From: Softwires [mailto:[email-masked]] On Behalf Of Yong Cui
> Sent: Monday, March 26, 2018 9:44 PM
> To: Softwires WG <[email-masked]>
> Cc: [email-masked]; Yong Cui <[email-masked]>
> Subject: [Softwires] WGLC on draft-ietf-softwire-map-radius-14
> 
> Hi folks,
> 
> Please send your substantial comments to the list during the last call. You are
> also welcome to send your editorial comments directly to the authors.
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Sun, 8 Apr 2018 10:08:37 +0000

Hi all,

I also support it moving forward as a co-author.
The MAP-E/T had been used by some operators, thus this document is useful for real deployment. Btw, the document was changed to get more comprehensive to cover different scenarios in the latest several versions, the authors (mostly by Yu Fu) really did some essential work on it.

Best regards,
Bing

---

From: Peter Li <[email-masked]>
Date: Sat, 14 Apr 2018 14:57:22 -0700

Hi all,

Sorry for the delayed reply, as a co-author, I support moving this document
forward. This document has gone through a number of revisions addressing
comments of the wg, the authors put a lot of effort to make this an intact
work covering multiple softwire scenarios.

Best,
Tianxiang

2018-03-26 6:43 GMT-07:00 Yong Cui <[email-masked]>:

> Please send your substantial comments to the list during the last call.
> You are also welcome to send your editorial comments directly to the
> authors.
>