Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

Dmitry Anipko <Dmitry.Anipko@microsoft.com> Mon, 04 November 2013 00:19 UTC

Return-Path: <Dmitry.Anipko@microsoft.com>
X-Original-To: mif-arch-dt@ietfa.amsl.com
Delivered-To: mif-arch-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C0311E825F for <mif-arch-dt@ietfa.amsl.com>; Sun, 3 Nov 2013 16:19:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrZxNhuscb9o for <mif-arch-dt@ietfa.amsl.com>; Sun, 3 Nov 2013 16:19:20 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id A88E611E825C for <mif-arch-dt@ietf.org>; Sun, 3 Nov 2013 16:19:19 -0800 (PST)
Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB078.namprd03.prod.outlook.com (10.255.175.154) with Microsoft SMTP Server (TLS) id 15.0.815.6; Mon, 4 Nov 2013 00:19:16 +0000
Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.119]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.119]) with mapi id 15.00.0815.000; Mon, 4 Nov 2013 00:19:16 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>, "mif-arch-dt@ietf.org" <mif-arch-dt@ietf.org>
Thread-Topic: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains
Thread-Index: AQHO0Al1EuDFRbK3sEiC7iRTvO04C5oURpXp
Date: Mon, 04 Nov 2013 00:19:15 +0000
Message-ID: <0010ca0ba1f44fe2a1b8fa5f110a00c0@SN2PR03MB077.namprd03.prod.outlook.com>
References: <5267F29C.3010304@ericsson.com>
In-Reply-To: <5267F29C.3010304@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.134.140.50]
x-forefront-prvs: 0020414413
x-forefront-antispam-report: SFV:NSPM; SFS:(45984002)(189002)(377454003)(199002)(53754006)(83072001)(15975445006)(56816003)(76576001)(77096001)(81816001)(76786001)(76796001)(19580395003)(85306002)(80976001)(76482001)(83322001)(79102001)(74706001)(87266001)(19580405001)(81686001)(33646001)(74502001)(15202345003)(74662001)(51856001)(31966008)(59766001)(74366001)(561944002)(74316001)(77982001)(56776001)(54316002)(65816001)(63696002)(80022001)(81542001)(66066001)(50986001)(81342001)(47446002)(46102001)(53806001)(4396001)(74876001)(69226001)(47976001)(54356001)(47736001)(49866001)(2656002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:SN2PR03MB078; H:SN2PR03MB077.namprd03.prod.outlook.com; CLIP:64.134.140.50; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains
X-BeenThere: mif-arch-dt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: MIF Architecture Design Team mailing list <mif-arch-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif-arch-dt>
List-Post: <mailto:mif-arch-dt@ietf.org>
List-Help: <mailto:mif-arch-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2013 00:19:25 -0000

Hi Suresh, Jouni, Shwetha,

thank you very much for sharing this work, I think this is a great start. Please find comments below. 

-Dmitry

Applicable to both DHCP and ND:

1. The drafts say there must be strictly one OPTION_PVD_ID in each container.  It makes sense for the particular type of ID, but I wonder whether this removes an ability to have the PVD named by different types of ID (UUID and UTF string, perhaps human readable) at the same time?If the latter is desirable, should multiple ID options, with different ID type each, be allowed in one container, or should there be a different solution for such scenario?

2.  The drafts say or imply that one of the things the container signature does, is that it can prevent unauthorized config source, such as a router or a DHCP server, from advertising a PVD it is not authorized to advertise. But it is not clear (at least to me), how that the use of the signature actually achieves or can achieve that? 

3. Both drafts mention timestamp as a protection against replay attacks. If that's the recommended solution against what's considered to be a fairly common relevant attack, shall the timestamp option be described (or already existing, if any, option be referred to)?

Applicable to DHCP only:

4. There seem to be possibly conflicting / ambiguous language about OPTION_PVD_AUTH in different places in the draft: "Every OPTION_PVD option SHOULD contain at most one OPTION_PVD_AUTH option" vs "The PVD container option SHOULD contain exactly one OPTION_PVD_AUTH". Remove one of the sentences? (my guess the latter)

5. In the description of the  option, it is unclear, to which field in the option the following text refers to: "authentication/authorization information: This information is provided by the owner of the provisioning domain and is passed on unmodified by the DHCPv6 server.".

6.  In client/server behavior, it seems to me, there is a mismatch between the client and the server behavior: the client is said to include OPTION_PVD in OPTION_ORO if it wants to get info from *all* PVDs (my guess, as opposed to individual PVD?); while server is sad to not send any PVD info if OPTION_PVD in OPTION_ORO is not present.

7. Related to 6, in the server section, it is unclear whether the intended use of OPTION_PVD in OPTION_ORO is to indicate client support for PVDs (as the first bullet seems to imply), or client interest in all PVDs (as the third bullet seems to imply).

Applicable to ND only:

8, There is currently no separate sections for client/router behavior (as in DHCP). Should it be added? (may be particularly helpful to discuss the potential differences between formation of solicited and unsolicited RAs, and clients interested in all PVDs/interested in particular PVD)

9. The language "after subtracting 'Options Count' times suboptions from it", if read literally, is probably not correct (multiplying only makes sense if all the lengths are equal).


For differences between DHCP and ND:


10. The formation of PVD signature is done differently in the drafts (in DHCP - the last option in the container, in ND - part of the container option) . Is there a reason for this (such as, potentially, consistency with other precedents in DHCP/ND)? (if there isn't, then arguably having unified way to verify messages can make implementations simpler)

11. The formatting of how variable number of sub options in the container is accommodated in ND vs DHCP, is different - in one cases, there is a field, explicitly indicating number of options, in addition to the length of the container and each option, in the other case it is based purely on lengths. Is there a reason for that?

12. OPTION_PVD_ID in ND has ID-Length, in DHCP it doesn't. Similarly,  differences in the \0-padding language.

 

________________________________________
From: mif-arch-dt-bounces@ietf.org <mif-arch-dt-bounces@ietf.org> on behalf of Suresh Krishnan <suresh.krishnan@ericsson.com>
Sent: Wednesday, October 23, 2013 9:00 AM
To: mif-arch-dt@ietf.org
Subject: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

Hi all,
  One of the action items from the meeting two weeks ago was to write up
a strawman solution proposal for DHCP and RA options to carry
information about multiple provisioning domains. Jouni, Shwetha and I
worked on it and came up with these initial drafts. We would love to
hear your comments.

The DHCP version is at

http://tools.ietf.org/html/draft-kkb-mpvd-dhcp-support-00

The RA version is at

http://tools.ietf.org/html/draft-kk-mpvd-ndp-support-00

Thanks
Suresh, Jouni and Shwetha
_______________________________________________
mif-arch-dt mailing list
mif-arch-dt@ietf.org
https://www.ietf.org/mailman/listinfo/mif-arch-dt