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

ianfarrer@gmx.com Wed, 01 April 2020 18:29 UTC

Return-Path: <ianfarrer@gmx.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 A34D33A07B7; Wed, 1 Apr 2020 11:29:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 9sNmuXrSNtdC; Wed, 1 Apr 2020 11:29:10 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354763A15E5; Wed, 1 Apr 2020 11:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1585765743; bh=EYdsXmd+C/J4tMkN5KSKsVD2CF+3znX1p8MGwwmbIig=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=QtiaYyeA5e8lXhIOzdGe0To9efllHLNJT8oJKDLIPzEYOVkTXUDYfP37aifcz3B/3 p+Kb0D6WNg6Hr99nNSf0cB+XOiGK5sVSq9DFz205h5KYtPa/HtQWdtrvSaSJw9BHTe iwPpPEBa+Pvsg4/B/LBa06+ZsDD1jVZo6SknsKVI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.128.73] ([78.35.165.203]) by mail.gmx.com (mrgmx004 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MhlGk-1iol4x0qeG-00dqzK; Wed, 01 Apr 2020 20:29:03 +0200
From: ianfarrer@gmx.com
Message-Id: <D847C596-F3D0-4165-BA5B-32E0D4E7BA35@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_94DF31FC-A813-49A0-98F0-D790E59AD091"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 01 Apr 2020 20:29:02 +0200
In-Reply-To: <75369E25-F0D9-47A5-A94C-EF40736656FC@cisco.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>
To: "Bernie Volz (volz)" <volz@cisco.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>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:nbOOTPpFv/DHL6wIknFajgPwhAvpHCoGSRhmqOaCGEzlsWW+iXE UjXW77+horhIdn3GZMnh5EcTjuMjQhrfOpm8hXQ28BBlpmKcHgNtbV/0+5WU+ISy3krEJiG o0DSNUaJx1SX56Mj9yI/joeVjbqL/epY0+rUavTzQkJoDpGaht7iehm142Pa7wSNe2UlAO7 UJw+5KBmaYuFUZwwHZDCg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:dQNGoZ4KZPs=:WKS9ook66nNZAtSwMFbjgF eA1KvMUXgN4YIan8khxIxj3dSOtg6y5vS112pelL23ndgT0VIPF1HKaqvqzRqC1354ctz6R9R XCzvt3w7g7XVVNJ42mvhSNRSO9kYGuF7aGnfikVpWtf+sSSb4p2dzcyjM/ViKdIH6cjz3MGFX xWcUYyWMkgdGWP0CaSc7w652azjBFCQMXcaWvJZhKxf4nzx5Spl/jKr53AM5vVuK64nPr+BJe 5N1eT5Jtwm72GjQH2k7JaM9LgcGxufFLhbKVQmbfbj+rptBe/UOEVm5Fl39hSf7XwFTIkknMn tMyg7A3RauMZw+2+ILZc4dkuq+tdTPI6QpElDGrrgyMjtQlb5VoWoEUxLZJchclsNoL9d/cC1 hQkQRHag+d5j0OfSnjn36AFWKWtvnj6alSYzzunaTJ5ufPaRFWBHEEmihfzYYBV6pbD1bIebU zV+4UGTKjjkFHyfyup1kLqIxCovbp0+dwkv5/nzSM1RtnZ8nTzFrP/EEdS7KhUG6b0HG3Kc2x pFq3MSzAjs0OJ0KUq9NrAylcCgXrm364fj9kd6MiEQPWBiK5zpgaR5BZJncWrphzUcy13w7JD p2XUa3mXM2KbQnSIueDMVrlpRiTeHUF6SyVvIDISJeJ/6fjUnhDpBS3yKqgCdYu+ZdMl25Ems hthAflBzM8BKPjQFrISI1+eCyolNW0vxhBN2TJ4axY6XCAjyjB+JtpBX1nJ+1ol6pbEiTTrQ7 8Y6v7Mc7HFY+mswlPUH6kXv/UWIp0DklGAuIybNj70HHBfcndifxn+ZsIp9jt8lbqEjihouOy MCxqoBjqHGP61cDhkHGPWwoI6cY6JlSv1sHuQvtDH5p0bnT/60ftFsoA0wVXQeaoWILU7td2C KHWkaXjEpMMl7L8vB5a15tCJCiMm9RgXaLdpN/XBTAUMpvWsn1GfQe5zuo5gfrtpPVkB5W6So Ypk1I9MQz5t9PIH3rV91YXe6pdeqVp0nfx0FrnoRJL1lC4pD+53LMiQailWTZ2YGyhW63p3G9 QP3KLTkMejAeaHTC/BaER5OxxmCcEZqNFqQqhaFZK8XnvBg2SzqViCIasWGBPnRDlcc1ER1KM Pc9cnlaSc9wAt+sts2OhPTWItHnmhjUD19e1pCW8THB8zMYJNHACvstIwe1pkPhuogGaeg6kN sAtat5cJriXPVqbmaG7gl0FzXvUXAHcpvbFwF5vklL5Y/SQqoUTJmxE/vpZ0U8r2ommyRRSIa gRQSNYUPa0rTo80ZR
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/daLFh4MYptjb8PB5L9ARa7g1dqI>
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:29:13 -0000

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.]