Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

"Bernie Volz (volz)" <volz@cisco.com> Wed, 01 April 2020 18:42 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D8A3A160D; Wed, 1 Apr 2020 11:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=G2JBpQOt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CKq76zOA
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 EejMlk1TxACf; Wed, 1 Apr 2020 11:42:48 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128D13A1644; Wed, 1 Apr 2020 11:42:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35750; q=dns/txt; s=iport; t=1585766563; x=1586976163; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/VqzXBYOpjfoh+Vz+cihKVVRASLExnUYVQaxcfIBIdY=; b=G2JBpQOtSbgqr/SXQIXkQUc6btvYSSMc3SfppftrDBotc3YoIRTpLF/Q WsPKg4er6gb5YtrsC4T1vjYgmT1fNK7j9hWZ+oa5klVQ7ktSzlDvpe6c9 WCrOAv/lbpS00upLoR5Nri0bRQnHyx1OB1md5nqRfmwvAMFAdtEShXvPb 0=;
IronPort-PHdr: 9a23:teANaBfphriSIzm36MfgoINjlGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwKUD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFlcejNkO2QkpAcqLE0r+eeDtaz4SF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3BgBn34Re/5pdJa1mHAEBAQEBBwEBEQEEBAEBgXuBJS9QBWxYIAQLKgqEEINFA4ptgl+YHYJSA1QKAQEBDAEBLQIEAQGERAIXgiEkOBMCAwEBCwEBBQEBAQIBBQRthVYBC4VwAQEBAQMSEQoTAQE3AQ8CAQgRBAEBIQoCAgIwHQgCBA4FCBMHgwWBfk0DLgGkMQKBOYhidYEygn8BAQWFIBiCDAmBOIwxGoIAgRFHgU9+PoIegggQGoMQMoIsjgCDBIV+gl6HUI5ceAqCPZc9gkyIM5BzjyeBUpo8AgQCBAUCDgEBBYFpIoFYcBWDJ1AYDY4dDBeDUIpVdIEpi0qBMgGBDwEB
X-IronPort-AV: E=Sophos;i="5.72,332,1580774400"; d="scan'208,217";a="469348919"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2020 18:42:42 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 031Igftc027265 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Apr 2020 18:42:42 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 13:42:41 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 13:42:41 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 1 Apr 2020 13:42:41 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KJ0EdfmzpWCzWJwJQQ4YrN9NqQBE/qHBevSY7h3EKPUwMqlFP7cPL/IcFKETp8McGNJTTeokeTJcr+4poTpY3pDb/BYky6m3802SRiqiJL/cvcm1MRpJpSye830r/Wrq2FeB8H4xtsl26neX0ju/9NhppLa4m69MPl3iAYeTvF/xlMeOeBlhTMPeYKonn4lbId9ICfX5QSiO4Pn6t5FAUZpxxCXPa7zhRqT+vk7XpQ/iFrVnufRSGJkxGQxD/cN2534gV3nWFPWBVV3ee+oJ9EpkZzT1wUTIZajbdUJEusNINHMM3VWvmOvjh1iDirXEme/+mYBErChLpJlT1Or1UA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/VqzXBYOpjfoh+Vz+cihKVVRASLExnUYVQaxcfIBIdY=; b=SM89RI4DHLWThs/TcXAYAyhZPI8gIwydxITtf3D35+NzWuRTIVd2UWTw/Mll16kfP17iw2t57fOtJYzk4RpRZBWAI+16j5EXyGxY+mvIfBSQE9B9mEucljWc3a/q+O3RtBZUzksgDyEkL/LlKGOkXZCQ+4KMlraAiUnpciZPzaddzqrf+4sr218EO9UAbQDLMpoyanYqx72vKHAkpgOuDMliqX4UMEpjZoTMItEs0WWX62AFhB/TXcOqXPbQ6n8bm7ZhdNdc77jjku1ZBQwp4+OY1JxSCNJQBZNNAbnnJk3gaNL8/QAw7hc/NBB8sKPWD0zgaqeQRsQJsj44E4NQbA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/VqzXBYOpjfoh+Vz+cihKVVRASLExnUYVQaxcfIBIdY=; b=CKq76zOADJjOW6+OGhY1P6ypyYbtbdnhI/Atx0zM86vqPctZ/+6ePJ5XdCn6OxvFirCk1UQdjAbr5NlSOBO7RKvpYtqDaU/m3t4wCZ5HYtVDad80kYQporB27r2BQ4enTPaTs+vQv8YZSXduUlAocI5V0I0WupHfBT36viZ0hjA=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2802.namprd11.prod.outlook.com (2603:10b6:406:b7::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18; Wed, 1 Apr 2020 18:42:40 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::29d4:9c08:fa95:c26e%7]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 18:42:40 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "ianfarrer@gmx.com" <ianfarrer@gmx.com>
CC: "draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org" <draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt
Thread-Index: AQHV98bEC9/aF5Xkw028jQpGj8sRqKhDn3CQgAGc4gD//8IOgIARUXJQgANV7eCAAY4agP//65+AgAmXzwCAAALb0A==
Date: Wed, 01 Apr 2020 18:42:40 +0000
Message-ID: <BN7PR11MB254768A96E2FCD8A56C92138CFC90@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <158346050095.14620.2547383825421375669@ietfa.amsl.com> <CANFmOt=21NNyYom9KtVQ7x5mTE6rR2GAAg8DwAdaptuOWAJLrQ@mail.gmail.com> <BN7PR11MB2547E17639F673343B5210BBCFFC0@BN7PR11MB2547.namprd11.prod.outlook.com> <CANFmOtnWHJzNtw8-aj+Dqgbqh0aeDMVtXcnib0RC4Bpi+OW0eg@mail.gmail.com> <43727BCE-732F-4629-8BCD-EBCDE2507B82@cisco.com> <BN7PR11MB2547273DA5E1D5F39F26629ACFF00@BN7PR11MB2547.namprd11.prod.outlook.com> <BN7PR11MB254754D841622448F49B021ACFCE0@BN7PR11MB2547.namprd11.prod.outlook.com> <98E34F29-CAB3-4FC3-9B53-AB17AF811683@gmx.com> <75369E25-F0D9-47A5-A94C-EF40736656FC@cisco.com> <D847C596-F3D0-4165-BA5B-32E0D4E7BA35@gmx.com>
In-Reply-To: <D847C596-F3D0-4165-BA5B-32E0D4E7BA35@gmx.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com;
x-originating-ip: [24.233.121.124]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e5b0a4bc-8566-4161-18c6-08d7d66c74de
x-ms-traffictypediagnostic: BN7PR11MB2802:
x-microsoft-antispam-prvs: <BN7PR11MB280249CA63D094B0E41249CBCFC90@BN7PR11MB2802.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(39860400002)(366004)(136003)(346002)(26005)(186003)(33656002)(66946007)(316002)(76116006)(2906002)(5660300002)(71200400001)(66446008)(4326008)(9686003)(66556008)(478600001)(52536014)(8936002)(54906003)(55016002)(64756008)(81156014)(7696005)(66476007)(86362001)(81166006)(66574012)(6506007)(6916009)(53546011)(8676002)(518174003); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pftIbmPBqPEjpEPLsUQpP1tPw7fXa3E28ClGMchDgB7wxlmqYxRDqgoLOzbQD4E2RarBPT3GzlPdH7CH/pXOjlo66JIMy382eW4U+JOB6FEpPNd8ZQlWk8IJZXdVSWpOYChf1+x/72LYXMF4g6vUjpJTihFLff2sllIhdKozJrhIcs/wB6fPiXnvXjFm4TRHwuWVurIi2mRc5+BqNVQO0JkWmQLKhnlh5ECR/3dkzklzsM6gmaCepZXYpTrrD5hGxcDvGv7dmwvDXdOhyBo19xdhLdF8dgxFC1cbwTRFCxa0D6e7Neo0o2k5NNPYjxfEsqj+EFzdqr5xktApGBaAJZX4XgiwkK/S03Hc6oANy9QkMyPuTVbpJ3g0MA1ok6rKua20QJAwyfl902wJzdJaH+SMFYcQUPusiNQXBPpjzSnbLA3yzXe+Nw87usm/Iv4ZgvxIZKdPIeiwL+NDOOK6QHQ5UtCAouM+hetr/6rd058v8MaTyVC77Y9QKUz4ku6v
x-ms-exchange-antispam-messagedata: oUx2Txss8y0HJrEfZoNE3uHPA93BSJwWFOaLOWiqZlJCihM3SAKOiLKaV0SqD+7xLTpj8LsEoXWlAv4U26Fj6E5QSr1fAWVQ06I8L2bTSTJ/djD2tRgEyBruvEnaTMXjLb9Hzs6ayD+yjkYxlDN2OQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN7PR11MB254768A96E2FCD8A56C92138CFC90BN7PR11MB2547namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e5b0a4bc-8566-4161-18c6-08d7d66c74de
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 18:42:40.0789 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ClcVJxpSpG8FCm3GlM1N01BRa8wtB2iCk1U/IO+dCKRX/XVqlMDbvWP/Hgw0utkP
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2802
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/sk-IM5gSQPrIistauhD3defIMEo>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2020 18:42:51 -0000

Hi:

For G-5:  OK … so G-4 says to do it for a single interface, G-5 says to do it across multiple interfaces (of the relay).

And looks good for other issues.

Thanks!


  *   Bernie

From: ianfarrer@gmx.com <ianfarrer@gmx.com>
Sent: Wednesday, April 1, 2020 2:29 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: draft-ietf-dhc-dhcpv6-pd-relay-requirements@ietf.org; dhcwg@ietf.org
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

Hi Bernie,

Please see inline below.

Thanks,
Ian




   G-5:    The relay MUST allow the same client identifier (DUID) to
           have active delegated prefix leases on more than one
           interface simultaneously.  This is to allow client devices
           with duplicate DUIDs to function on separate broadcast
           domains.
- See earlier my points in section 3.4; not sure how best to “modify” this item.

[if - What about changing to:

The relay SHOULD allow the same client identifier (DUID) to have active delegated prefix leases on more than one
interface simultaneously, unless client DUID uniqueness is necessary for the functioning or security of the network.
This is to allow client devices with duplicate DUIDs to function on separate broadcast domains.
]
BV> OK, but I guess I should have raised this earlier but what is meant by Interface? Who’s interface? Do we need “on more than one interface” in this sentence?

[if - Good point. This is intended to cover deployment scenario where a single L3 router has many customer facing interfaces each with a relay function. So, to clarify this:

If a device has multiple interfaces that implement a delegating relay function, the device SHOULD allow the same client identifier (DUID) to
have active delegated prefix leases on more than one interface simultaneously, unless client DUID uniqueness
is necessary for the functioning or security of the network.
This is to allow client devices with duplicate DUIDs to function on separate broadcast domains.

]



   G-6:    The maximum number of simultaneous prefixes delegated to a
           single client MUST be configurable.

   G-7:    The relay MUST implement a mechanism to limit the maximum
           number of active prefix delegations on a single port for all
           client identifiers and IA_PDs.  This value SHOULD be
           configurable.
- For G-6 ad G-7, are there some recommendations about what (a) a reasonable number to support is and (b) what the default should be? While it would be great to have this be “unlimited”, likely equipment manufacturers might like some guidance. For example we could say that “While allowing this to be fully configurable, delegating relays should support at least 8 per client device and use this as the default limit.” That’s just an example.

[if - This is a good question. We could add another requirement here recommending that the delegating relay supports at least X prefixes per client. The question is what value? I’ve seen 4-8 in SP edge routers, so I think 8 is a reasonable value, but I’m not sure whether this is reasonable for CMTS/BNG etc. Any insight would be appreciated here.
]
BV> Yeah – I don’t have any direct insight. I agree that 8 is a reasonable value as I would hope it would never be that many to start with.

[if - I’ll go with 8 for now and hopefully we’ll get some more feedback during last call. For the wording:

          G-7: The relay MUST implement a mechanism to limit the
            maximum number of active prefix delegations on a single port for all
            client identifiers and IA_PDs. This value MUST be configurable.

          G-8: It is RECOMMENDED that delegating relays support
            at least 8 active delegated leases per client device and use this
            as the default limit.

I don’t think that we need the ‘fully configurable line’ in G-8 as it’s covered in G7 (I’ve changed the old SHOULD to a MUST for the configurable statement in G7]



   G-8:    The delegating relay MUST synchronize the lifetimes of active
           prefix delegation leases with server.
- I’m not sure I completely understand what this requirement means. Are you suggesting NTP or similar time synchronization be used? As lifetimes are relative (seconds remaining, not absolute time stamps) in DHCP messages, I’m not sure why NTP would be that critical. As there are 3 places lifetimes would be stored (server, delegating relay, client), unless all of these clocks were synchronized, some drift should be tolerated (i.e., not all clocks will tick at the same rate).

[if - The important thing here is the lease lifetime synchronisation between the server, delegating relay and client from the timers in the Reply messages. No suggestion that NTP should be used for that as it’s the DHCP lifetimes that matter. As this is a requirements document, we didn’t want to define how the delegating relay performs this synchronisation (like with SAVI), just that this needs to happen. Do you think that this is the wrong approach, or is the requirement text not clear as to the intention?
]
BV> I think perhaps this could be worded in a different way? Perhaps something like “The delegating relay MUST update the lifetimes based on the Client Reply messages it forwards to the client and only expire the delegated prefixes when the valid lifetime has elapsed.” Isn’t that really what you are after?

[if - OK]


BV> I also wonder whether there is some value in pointing out that “snooping” Client Reply Messages cannot capture which delegated prefixes have been released; Client Release messages must be monitored instead. (While it was something I had noted but for some reason failed to bring up during the RFC8415 discussion, it would have been a nice change to allow a Server to send back the “released” leases in the Reply to the respond with the IA_*/IA* options containing 0 lifetimes. This would have made snooping a bit simpler as I think then it would have been possible to just snoop the Reply messages.

[if - This could actually be a problem for e.g. a user is being DoS’d. Even if they were to release their current lease, change their DUID and get new leases the relay would continue to forward the DoS traffic to the old prefix until it aged out.

The 0 lifetime in the server response seems like a neater solution to me, but it sounds like that ship has sailed. What about adding the following in general requirements?:

G-10: On receipt of a Release message from the client, the delegating relay MUST expire the active leases for each of the IA_PDs in the message.]