[Softwires] Fwd: Review of draft-ietf-softwire-map-radius-08

Ian Farrer <ianfarrer@gmx.com> Tue, 15 November 2016 09:25 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EE3121296F8 for <softwires@ietfa.amsl.com>; Tue, 15 Nov 2016 01:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5lYs8TNXOSdW for <softwires@ietfa.amsl.com>; Tue, 15 Nov 2016 01:25:55 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA60129450 for <softwires@ietf.org>; Tue, 15 Nov 2016 01:25:54 -0800 (PST)
Received: from dhcp-9645.meeting.ietf.org ([]) by mail.gmx.com (mrgmx001 []) with ESMTPSA (Nemesis) id 0LcBBl-1cYFJq0uFZ-00jWDU for <softwires@ietf.org>; Tue, 15 Nov 2016 10:25:52 +0100
From: Ian Farrer <ianfarrer@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D342B860-473F-4A29-8626-61D855D969A5"
Date: Tue, 15 Nov 2016 18:25:47 +0900
References: <3052CDB7-4A58-44A8-B009-C4B93FD190A3@gmx.com>
To: softwires <softwires@ietf.org>
Message-Id: <ABB5BE3B-8C76-4BBD-BB31-A101FC5C2CE4@gmx.com>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Provags-ID: V03:K0:0khb7VjwaBY9HkHhbs5cbuWIXy3/9pGiNnuw4GoGauCLXRwgNEd VB8fT6MZIhAhE1suAVFbXVj+uwt4sRrC5LqDwRHDUXBnZdMQfjb+/lLRXEpFF+CvtQbjUAX v0BlJY9cAToZcVVSaL42uV/S6ZYUw/o358t5xusY5IOq//IYhL+rVy7RQrx6i31SBCHVSED 0gapkb1pxarw+BOBsS+BA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:PsnuVkjcqIs=:ffI9MVEu3nAwF4M4GPYxtm tPglTRBj8/iqRMS9ydKBFNwg52/FhDeFsOoHOrzjWRlk40VTM3HwkCMrwBbI5WqX1Zxj60rpq C1KHYzjD/90kPqpex4fBGCtzrHzWkvw8NwNYPAgxgwY70QOBQDbejPRAzsUUvNLWyIL3kTXj1 IbjPYXOFLZQj5fNu8w6IMjteE1y5xVVt8qzyrLdpHFF05pl7iviAYj6bd2hMP13ol4aC+ehDO 5B3aU34qC+Xx3onyJAC8aPZilP7Mq6I6X4cZbCAZ1+YKN246La46yh4nr/hxsUmc4JxzLnJ0O VWHxuIzdhniB03lrS2BMGPsxFnqltvI52Vx+NZdfYXhdAcEj5MEADFAlsgZzhbpcb5vG3lysq TzAcTngnyCS98orAtJI+X9W70map6amGNN7TR9sTSzG5UJpprOJ48GIxEE9SG04NjTQUFqOoQ sjhXJBvGQc1wriOe+XzRYHsSEIPdKctNQhyPCTOWnY5mb64hzWUNSucMXJecncfdvnijDKDPC n4NtWrkMqUGHqAVHh5yIA7lb19l8l79Qlkk4of1xmmV4vElF5peZeicQEofEJTptmINphGn7g dZUADPnn+Th7oUYvfPFZePfvMOL6u5XXwOz1RNvzfoWuYCEdTXmQrwY6jo+9njLX/dgM4by7s utHZ8QMPqiqmV72jGMNH9cdBBoxk8HeXUVGDed4pZ/TikZKzTRz6yErhNoD4TT45pk+OAkaVd KDmzf9QCXovFNLoaiOILiHDz3/UBY1KSRy76Hdkf1kD6BA36faXUIZNzHVwj2aoL9ATLyU8wq qcmcoS4
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/LUdaLRpyM522sRzr26fLaO1j1bk>
Subject: [Softwires] Fwd: Review of draft-ietf-softwire-map-radius-08
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2016 09:25:57 -0000


Here’s a review of the updated version of the draft.


General Comments:
Please do language review throughout.

Throughout the document, there are multiple places where the client is described as sending a ORO containing the ’S46 container options’, or similar (e.g. Figure 1, description text under figure 1). This should be 'S46 container option code’. Please revise throughout. 

Figure 1
4. The DHCPv6 advertise message will have an S46 container option as well.

General comment on figure 1 text
There is a lot of requirements language here that I think is unnecessary. The purpose of the text is to describe how the message flow works and this can be done without the need for RFC2119 language. The use of SHOULD, particularly in point 2 leaves questions like: under what conditions is it acceptable for the DHCPv6 server NOT to fill in the shared password, and what are the expected effects of this?

Figure 1 Text
4. Suggest "After receiving the Access-Accept message with the corresponding Attribute, the BNG SHOULD respond the user an Advertisement message.” is replaced with: "After receiving the Access-Accept message with the corresponding Attribute, the BNG SHOULD respond to the DHCPv6 client with an Advertisement message.”

6. The inclusion of DHCPv4o6 as an option here complicates things as it has it’s own set of message flows which are separate to this process. I’m not sure if this is also the case for PCP based provisioning. It may be best to limit the scope of this to the S46 options described in RFC7598 for clarity.

Section 4.2
As draft-ietf-softwire-unified-cpe-08 is just about to be published, and the draft allows for multiple S46 attributes, it would make sense to also have an attribute for OPTION_S46_PRIORITY so that operator prioritisation for multiple mechanisms can be supplied. This may need an IANA registry for the allowed values for this new RADIUS attribute with the same contents as Option Codes Permitted in the S46 Priority Option.
A pointer and some text for RFC6519 (DSLite attribute) could be included will also be needed.

Across all of the following attribute definitions, it might be helpful to ‘borrow’ the definitions in RFC7598 for consistency (e.g. which parts are variable, where 0 padding is used).
The Sublen is defined as being 18. Shouldn’t this be variable (but a multiple of 16) if it is a list of addresses?

BR-ipv6-address - This describes a single address, but the diagram shows a list of addresses.

The Sublen is given as 8. Shouldn’t this be variable (1 for prefix len, variable for the prefix).

(Note on this one, the RFC7598 text is wrong. It should allow values of 0-96 as described in RFC7599 Section 5.1. I have raised an errata on this)

This states it is a 32 bit filed, but it’s meant to contain an IPv6 prefix.

There should only be a single

The Sublen should be variable.

Is 6 the correct SubLen here (I don’t know if the SubType and SubLen fields should be counted in the SubLen)?

Section 7.
The word ‘proofing’ should probably be replaced with ‘spoofing’

Can the dictionary attack on the shared password be mitigated? As this communication takes place between the DHCPv6 server and the RADIUS server, wouldn’t the use of ACLs preventing users being able to send requests directly to the RADIUS server prevent this type of attack?