Subject: [secdir] SECDIR review of draft-ietf-softwire-map-radius-23

From: Donald Eastlake <[email-masked]>
Date: Wed, 29 May 2019 00:14:51 -0400

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

The summary of the review is Almost Ready.

This draft specifies new RADIUS attributes that correspond with DHCPv6
Options for a number of IPv4 over IPv6 protocols. The main scenario being
supported is that customer equipment connects to a Broadband Network
Gateway (BNG). The BNG then authenticates the user with a AAA server using
RADIUS. There is also a DHCPv6 server at the BNG and the value of relevant
DHCPv6 Options are populated at the BNG from the RADIUS attributes in the
response from the AAA server.

Section 6 provides Security Considerations. It consists almost entirely in
a list of references to security considerations in other RFCs.  This seems
pretty complete but reading it feels kind of scattered. It would be good if
a few sentences could be added and the maybe the material slightly
re-organized to make it clearer how the parts of the Security
Considerations fit together.

Trivia:

   - Although there isn't much questions here, I think it is usual when
   creating a registry that goes on an existing web page to identify that web
   page.
   - The acronyms BMR and DMR are only used once in the body of the
   document. Perhaps they could be dispensed with and only the spelled out
   version used at that one occurrence for each. There may be other acronyms
   like this.
   - lwAFTR should be expanded on first use.
   - There is a slightly awkward thing about the IANA Considerations
   section. The first sentence of Section 7 talks about requesting IANA to act
   but then each subsection redundantly requests action and, in fact Section
   7.1 request action at the start of each paragraph. Either (1) the first
   sentence should say something like "IANA is requested to perform the
   actions described in the subsections below." and all the other "request"
   wording should go away or (2) the first sentence should omit "request"
   wording and just say something like "IANA actions are discussed in the
   subsections below." and the "requests" left in the subsections.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: <[email-masked]>
Date: Wed, 29 May 2019 09:12:35 +0000

Hi Donald,

Thank you for the review.

Please see inline.

Cheers,
Med

De : Donald Eastlake [mailto:[email-masked]]
Envoyé : mercredi 29 mai 2019 06:15
À : [email-masked]; [email-masked]
Cc : secdir
Objet : SECDIR review of draft-ietf-softwire-map-radius-23

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  Document editors and WG chairs should treat these comments just like any other last call comments.

This draft specifies new RADIUS attributes that correspond with DHCPv6 Options for a number of IPv4 over IPv6 protocols. The main scenario being supported is that customer equipment connects to a Broadband Network Gateway (BNG). The BNG then authenticates the user with a AAA server using RADIUS. There is also a DHCPv6 server at the BNG and the value of relevant DHCPv6 Options are populated at the BNG from the RADIUS attributes in the response from the AAA server.

Section 6 provides Security Considerations. It consists almost entirely in a list of references to security considerations in other RFCs.  This seems pretty complete but reading it feels kind of scattered. It would be good if a few sentences could be added and the maybe the material slightly re-organized to make it clearer how the parts of the Security Considerations fit together.

[Med] Sure. I reorganized the text among the following lines :

·         Reminder of security issues specific to each softwire mechanism.

·         Known RADIUS vulnerabilities apply to this spec.

·         BNG-AAA server: The document assumes that a trust relationship is in place between the RADIUS client and server. IPsec/tls can be used

·         CE-BNG: pointers to the existing DHCP RFCs.

You can check at: https://github.com/boucadair/draft-ietf-softwire-map-radius/blob/master/wdiff%20draft-ietf-softwire-map-radius-23.txt%20draft-ietf-softwire-map-radius-23.pdf

Trivia:

  *   Although there isn't much questions here, I think it is usual when creating a registry that goes on an existing web page to identify that web page.
[Med] Done.

  *   The acronyms BMR and DMR are only used once in the body of the document. Perhaps they could be dispensed with and only the spelled out version used at that one occurrence for each. There may be other acronyms like this.
[Med] Will double check.

  *   lwAFTR should be expanded on first use.
[Med] OK.

  *   There is a slightly awkward thing about the IANA Considerations section. The first sentence of Section 7 talks about requesting IANA to act but then each subsection redundantly requests action and, in fact Section 7.1 request action at the start of each paragraph. Either (1) the first sentence should say something like "IANA is requested to perform the actions described in the subsections below." and all the other "request" wording should go away or (2) the first sentence should omit "request" wording and just say something like "IANA actions are discussed in the subsections below." and the "requests" left in the subsections.
[Med] Agree. I have already fixed this one in my local copy.
Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]<mailto:[email-masked]>