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

<mohamed.boucadair@orange.com> Wed, 29 May 2019 09:12 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E1C12004F; Wed, 29 May 2019 02:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLvAh0cjxtc6; Wed, 29 May 2019 02:12:39 -0700 (PDT)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FCC21200F6; Wed, 29 May 2019 02:12:39 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 45DQ3867Y1z3029; Wed, 29 May 2019 11:12:36 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 45DQ384vXczBrLm; Wed, 29 May 2019 11:12:36 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7F.corporate.adroot.infra.ftgroup ([fe80::d9:d3cd:85bd:d331%21]) with mapi id 14.03.0439.000; Wed, 29 May 2019 11:12:36 +0200
From: mohamed.boucadair@orange.com
To: Donald Eastlake <d3e3e3@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-softwire-map-radius.all@ietf.org" <draft-ietf-softwire-map-radius.all@ietf.org>
CC: secdir <secdir@ietf.org>
Thread-Topic: SECDIR review of draft-ietf-softwire-map-radius-23
Thread-Index: AQHVFdUaRMSSr8gmnES7BzA8wGZN6KaBzkBg
Date: Wed, 29 May 2019 09:12:35 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA9096E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <CAF4+nEHEvQpkBBx=D3djZdtrCC9WmrGihBEtZjad9Z33PbAC+w@mail.gmail.com>
In-Reply-To: <CAF4+nEHEvQpkBBx=D3djZdtrCC9WmrGihBEtZjad9Z33PbAC+w@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA9096EOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/9yATd8tUUlPHGAkOB3QLe3rZI7o>
Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-map-radius-23
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 09:12:42 -0000

Hi Donald,

Thank you for the review.

Please see inline.

Cheers,
Med

De : Donald Eastlake [mailto:d3e3e3@gmail.com]
Envoyé : mercredi 29 mai 2019 06:15
À : iesg@ietf.org; draft-ietf-softwire-map-radius.all@ietf.org
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.

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.

[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
 d3e3e3@gmail.com<mailto:d3e3e3@gmail.com>