Re: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)

Harlan Stenn <stenn@nwtime.org> Wed, 29 May 2019 10:10 UTC

Return-Path: <stenn@nwtime.org>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459E312006A for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 03:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 XnthULzQk3o2 for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 03:10:41 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282B212002E for <ntp@ietf.org>; Wed, 29 May 2019 03:10:41 -0700 (PDT)
Received: from [10.208.75.157] (75-139-194-196.dhcp.knwc.wa.charter.com [75.139.194.196]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 45DRL8440rzL7T; Wed, 29 May 2019 10:10:40 +0000 (UTC)
To: Fernando Gont <fgont@si6networks.com>, ntp@ietf.org
References: <155841904754.12856.3727925672753047210.idtracker@ietfa.amsl.com> <9d21f083-4cba-1dd1-f5bb-c95984d3127b@si6networks.com> <9d74c6e3-244e-fdd7-184a-0572f4f144cd@ntp.org> <25275d68-8c18-1616-f226-dffe7e21091e@si6networks.com> <20190528174208.11253a67@rellim.com> <1a133133-5d6a-ca96-6c15-73e6933baffc@si6networks.com> <2794A95B-B118-40BD-AD60-DCB50CC32717@latt.net> <2107d74d-02da-cbd7-7a12-2837cb2e47a2@si6networks.com> <ced4c6d4-c34d-3460-eccc-b5608fbd340e@nwtime.org> <b4faacdf-3d9b-5e47-2415-276ef3d7f3af@si6networks.com> <69295233-497e-fa31-3270-691407fb6f30@nwtime.org> <15a5c387-8a44-5d7e-404b-e953a7a81737@si6networks.com>
From: Harlan Stenn <stenn@nwtime.org>
Openpgp: preference=signencrypt
Autocrypt: addr=stenn@nwtime.org; prefer-encrypt=mutual; keydata= mQGNBFI2xmQBDACrPayw18eU4pIwCvKh7k0iMkAV9cvzs49kBppM+xoH+KKj4QWmkKELD39H ngQnT3RkKsTLlwxyLqPdUmeQNAY2M5fsOK+OF6EvwLPK9hbmE3Wx2moX+sbEUxJ2VzFhKSKb OPZALXwk1XxL0qBedz0xHYcDwaSAZZkEFXURv2pDIdrmnoUnq2gdC8GpoFJiXoUaCLSYzzaY ac4Njw7Mue8IqfzRQb70aMjXl/qmsmfmEVAyGXywDdc/ler4XSgiuYOV7Kf69bj9PFZZSMdJ MWgEyZH6lJ0TU5ccR2zp5ZRmWzQQkxJMyH2th7q0Nmz3aX4A0K4yE0Ba9/5Dr7ctpF15BrMF aEo4s5lwI6tUnkgMWo265mMzCz4mAPV/ac0w0OXQg7r9E2r0+dRapnzUlG43D0JLDqDr9uRR L6IrRQqoCWUC75lfmPYQYSlaTJaK68r3lXd0z1cXJUgVtEL5H3/Z71R2B20twcQVAnw2iIH6 L5vdrsIjHrMmkqRVbs9nNyEAEQEAAbQ5SGFybGFuIFN0ZW5uIChOZXR3b3JrIFRpbWUgRm91 bmRhdGlvbikgPHN0ZW5uQG53dGltZS5vcmc+iQG5BBMBAgAjBQJSNsblAhsvBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQyIwAt1pH+kBlzgv/QOg70vdj8wU/z97UPdlbxtN4THAB gfSX4N0VPKT5fjX1tFhuXZQAOv7wedR3Trh7TGteyg33TBAFf9A42mXZKi1IxAiQG118Hd8I 51rXwnugURIYQaIyQI+vbchRbwVyz+mVLTI/h6FdbsVzT4UFmir+ZMkb/XeZPu0HItk4OZHE 6hk+TuTiCnlqlCPLq371fXV54VOb91WZYD8EQFtK02QHGHsQqWvapdphiDVpYehmsPyiTESq NMKLVtjtyPkQ6S7QF3slSg+2q3j8lyxEA78Yl0MSFNU8B/BtKgzWP2itBOfi+rtUKg+jOY1V /s2uVk2kq2QmHJ/s5k5ldy3qVvoTpxvwBe0+EoBocTHYt+xxp0mTM6YY1xLiQpLznzluqg9z qtejX1gZOF4mgLiBIrhXzed3zsAazhTp5rNb1kn0brZFh6JC5Wk941eilnA4LqX8AWo0lmwo eb+mpwZK/5lNdage/anpVqft9wJ/8EcvST9TLUO4fPrmT3d/0LpWuQGNBFI2xmQBDADXLsBk I7CSa5UXlrNVFJQHER1VxRBKqjWWCh/8Qv9v3p3NrIc2UnhoZ1uWQ2voBGty5Xfy9k4afV5k WwDyRDUIb7PX+Tj4HjVVr7qvnOVe/0KzZpNq0Azd0ggFbsM+8mydktHIwJykW0NUsGwPRYuD OA0Lro0ohb5IiCt3sSQi1X1hYjo7O1Vmn8Gy/XYOnhnMux+5zDPO2yTkCNX5PocYi9IJJy6p Mq1yQV4Y2Dl8KtQzvtq55vCUxx6n0MMzFViGwNW6F4ge9ItO4tDScsgowDrHa208ehwOpv/i wjf93lCClQ6vaKmOBX872K/tdY/hwhxPPjgl1bcrOwMRYVemOPPehwnXH5bwclk1hvDQdkJQ 5pJOkE4VCryTF/iDAt4g2QnHocUwt3b6/ChUUWmj2GZ22OR12rbnCtLedwp0DpViKPUCQHBO vpgXdzE/L9zWar9fqM0EREMgfWbsJc9028qluCcFLIN1gYsq4cC+YGAcOu7HOI5orBBV4m9j XfsAEQEAAYkDPgQYAQIACQUCUjbGZAIbLgGpCRDIjAC3Wkf6QMDdIAQZAQIABgUCUjbGZAAK CRDfCQ/G52/8P/uWDACe7OEM+VETDRqjQgAwzX+RjCVPvtgrqc1SExS0fV7i1mUUxr/B8io3 Y1cRHFoFKmedxf8prHZq316Md5u4egjFdTT6ZqEqkK0hvv+i0pRpCa5EX9VIStcJStomZp8F cY34grA+EOWITaLQ4qNZUP7rf2e7gq1ubQTj7uLr6HZZvMZ5em+IvrOWEuWDI6yOiI6px04w RDfkoR2h6kgdw4V0PT4NjK9WYYKrVCf1bjLlVImNBEcXfvlUTrIYO8y6ptvoUsBQky5pQRvP 99Pn42WfyLy50aII6+vyudD4T0yLjXAz4KteUttxtIte64m/F9/7GEIZAxTUcLyOq/7bP4le h39jBckwc62iYzeK/VkU/bMMh2D68Z3QylMnhhcW27BcgQHPKsHhmFa2SNytYcuQiSdf9+pj 4i32ETz1nJAvYAAqgTF/0PL+8ZNQoEpe/n9woMKrlZrqD4EgFmhQ3bNVhlaXz1nuTZDrwPt1 yMxBuUNbCF4jFnaruwrSiGTRoIfUZQwAjQglahrV4/mcjfnvbNoseHX0PKd9q+wjg7MIjWqr f2CI8Fa6MdanqwYphz43I2yXANKFZuMWsWqyQYlvGuPUlUUcAL3stp24RkzDB1Q+JS0IZJST T2JSu0aTfUdWVNqr2UI19eX+zxbOTckSi3Ng14ezG8ZX194ZH10b8JzntQOwmA20pd5JDhug zQfASER+CZDiPPcQ4mvC4y7rMrfV6XGQbDynC3ekDxo8SC5SvjaczXMwXg6SZ8iFtEWmEwW9 r7zPjjIPDrX8w5LXBgxArM5o/HbERpc2EdAvMh1D7LC0SvmoE7fBKxsicVBe4h6vXjEZ+LLr /wuZiBld9OnxAUIpwptbBspO6WKTQYvgFH2OeDG27hiE5P4Xs4WSp5j9ez8OVB1iZnA2nCQ+ tNTjO8c+C/P92vPLx5+bpGRXTXMNaLh34PS3ZsYoUDkKZNhczRZUWJ7nynSbeeyF+QW7SLwA qY7O7dyk9LFTsfJqRQJ7tWnIAjJPCwmSgQ8Kl0UJ
Message-ID: <b2934164-045a-df3e-feff-f6eb5362f6a0@nwtime.org>
Date: Wed, 29 May 2019 03:10:37 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <15a5c387-8a44-5d7e-404b-e953a7a81737@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/N2d_Y4hud0akB8EugTTGN9UVya4>
Subject: Re: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 10:10:44 -0000


On 5/29/2019 3:03 AM, Fernando Gont wrote:
> On 29/5/19 05:18, Harlan Stenn wrote:
>> On 5/29/2019 12:17 AM, Fernando Gont wrote:
>>> On 29/5/19 01:20, Harlan Stenn wrote:
>>>>
>>>>
>>>> On 5/28/2019 9:37 PM, Fernando Gont wrote:
>>>>> On 28/5/19 23:20, Majdi S. Abbas wrote:
> [....]
>>>
>>> Employing predictable numeric IDs is bad practice. The current
>>> requirement (which cannot even be complied to in IPv4-NATed networks),
>>> requires a fixed well-known port for clients. i.e., the spec mandates
>>> against a BCP (port randomization) and on the well-known concept that
>>> employing predictable IDs is asking for trouble.
>>
>> By the same token, generally applying rules without fully understanding
>> the costs/benefits and other trade-offs is bad practice.
> 
> I understand that your implementation employs port 123 as the source
> port. You mentioned that makes the code simpler. That's probably also
> the case when using predictable IDs (e.g. resulting from a counter) vs.
> randomized ones.
> 
> Protocol-wise: could you state what are the drawbacks of employing
> randomized port numbers?

I think this point has been covered before, more than once.

>> The NAT case you mention is a red herring.  That case effectively
>> randomizes the port already, at least outside the LAN.
> 
> The point I was trying to make is that if it was so vital protocol-wise
> that a specific port were used as the source port, then NTP would not
> work across NATs. Of course it does work, because the client port can be
> anything.

This sounds to me like you're admitting you gave a straw-man argument.

>>> As noted in some other message, the analysis so far has focused on
>>> attack packets that might get tossed if the org timer is not valid.
>>
>> When would a packet with an invalid org timer *not* be tossed?  This
>> sounds like another straw-man to me.
>>
>>> There might also be implementation bugs (e.g., buffer overflows, or
>>> whatever) that happen before that.
>>
>> So what?  Really - what difference would the port number make if there
>> are implementation bugs of the type you now hypothesize?
> 
> Difficulty in hitting the four-tuple being employed for NTP?

How do implementation bugs play in to this?

The loopback test is one of the *first* checks that must be passed
according to the Standard.

>>>> Of course it's fine if NTP client goes thru a NAT gateway.
>>>
>>> That's an indication that the current requirement in the spec is bogus.
>>> In fact, if you actually mandated it (e.g., the server were to require
>>> that the client port be 123), deployed clients would break.
>>
>> RFC5905 section 9.1 says:
>>
>>    srcport: UDP port number of the server or reference clock.  This
>>    becomes the destination port number in packets sent from this
>>    association.  When operating in symmetric modes (1 and 2), this field
>>    must contain the NTP port number PORT (123) assigned by the IANA.  In
>>    other modes, it can contain any number consistent with local policy.
>>
>> Where is the "current requirement in the spec", and who is proposing a
>> "mandate"?  
> 
> Yes, my bad. This is open, without a recommendation on what to do. The
> implementation I was running was indeed using port 123.
> 
> 
> 
> 
>> You are very certain of the number and scope of your use-cases.  I
>> believe the problem scope and use-cases are more diverse than what you
>> describe, and your solution, while appropriate for some of these,
>> *prevents* detection/remediation in other scenarios.
> 
> Not much like that. Actually, I was analyzing traffic, and then going
> through the spec, and surprised the client port used by the
> implementation I was running was employing port 123. Tried to track why
> that was the case.
> 
> Having worked on predictable numeric ids for a number of protocols, I
> expected this to be an historical artifact, in the area of "yeah,
> sure... we should have been randomizing it", do the recommendation and
> move on.
> 
> 
> 
>>> That's orthogonal to this. You don't need to leak the session ID in
>>> order to run a NIDS. -- and, no matter what you have in mind, I'll
>>> repeat the above: the requirement is in "SHOULD" level -- you can go
>>> against it if you have a really good reason to.
>>
>> I'd be a lot more receptive to your points if you showed more awareness
>> of the tradeoffs and identification of the various problem scenarios and
>> use-cases, and made proposals that were better rooted in reality.
> 
> I'm still trying to figure out e.g. what your implementation does or
> expects to do when you e.g. receive NTP packets with right four-tuple
> and, say, invalid org timer. Anything else other than toss the offending
> packets out? And, if that's the case, why are you interested in
> processing them instead rather than have them tossed before they get to
> the NTP process?

You're really having trouble finding out the answer to this?

I was told that you are generally diligent and a "deep diver" into these
sort of problems.  I'm not seeing that here.

>> But I'm not sure anybody besides me cares about my opinion/position on
>> your proposal.
> 
> FWIW, I'm interested in your feedback.

OK, thanks!

I'm still replying to your posts, if that's an indication.

> Thanks,
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!