Re: [Ntp] I-D Action: draft-ietf-ntp-port-randomization-04.txt

[Harlan Stenn <[e-mail]>]

On 6/22/2020 2:39 AM, Miroslav Lichvar wrote:
> On Mon, Jun 22, 2020 at 02:08:55AM -0700, Harlan Stenn wrote:
>> On 6/22/2020 1:59 AM, Miroslav Lichvar wrote:
>>> It depends on the UDP connection tracking timeout and the client's
>>> polling interval. A typical polling interval is longer than a typical
>>> tracking timeout, so the effect shouldn't be significant on average.
>>
>> I'm not sure exactly what you mean by "the UDP connection tracking timeout".
> 
> A stateful firewall is tracking connections. That includes NTP
> requests and responses. As it doesn't have an infinite amount of
> memory, it needs to drop the connections after some time. For UDP
> connections that timeout tends to be very short, e.g. two minutes.
> 
> I thought you implied with your question that port randomization will
> significantly increase the number of connections that the firewall
> will need to track.
> 
> What problem do you see with firewalls and port randomization?
> 
> ...

My primary concern about this document is that it seems to come from a
specific and limited point of view, and to me its tenor is one of
dictating an over-reaching "policy" instead of providing "mechanism".  I
think the draft should offer information and direction, from a wider
perspective.

Specifically, when I asked a network wizard about why he disagrees with
this proposal he tells me:

> Because on-host is a relatively unusual place for a firewall to be
> run, and most enterprises run firewalls elsewhere, and don't run
> them on-host because it is "so hard".  Enterprises are SO resistant
> to doing this that new technologies such as "microsegemntation" and
> "{smart, artificial intelligent, etc} firewall" that use other
> capabilities, such as a hypervisor's virtual networking subsystem
> (see VMware NSX) to force network security upon a VM.  This has the
> upside of being something that the VM itself cannot modify or drop.
> Unfortunately, it is mostly only for VM's, as a bare metal host
> does not have a virtual netwoork stack sitting on its network
> port anxiously filtering its packets.
>
> In more conventional designs, you will tend to have a dedicated
> firewall at network edge (to your upstream), and/or maybe at the
> router interface/default gateway for a host.
>
> Stateful filtering is mostly a game for software firewalls and
> software routers.  You need to maintain state; the silicon to do
> this is horribly pricey.
>
> However, I can do 10G line rate filtering on a switch with just a
> few commands (8.8.x is just example public IP space):
>
> ip access-list storage1-out
> 1000 permit ip 10.249.2.0 0.0.0.255 any
> ...
> 1190 permit tcp 8.8.64.72 0.0.0.3 eq smtp any
> 1200 permit udp 8.8.64.76 0.0.0.3 eq ntp any
> ...
> 1310 permit icmp any any
> 1320 deny every
> exit
>
> Now this configuration would happen to allow source port
> randomization, because within my network with the source
> "8.8.64.76/30:123" is guaranteed to be the NTP servers, but in a
> less-controlled environment such as where you are using pool,
> you would omit the source IP range and do something like
>
> 1200 permit udp any eq ntp any eq ntp
>
> which permits ntpd to work but doesn't allow scanning of random UDP
> services by an external site using a source port of :123.

and his last sentence carries the kicker.  This proposal effectively
cost-shifts filtering to hosts, and prevents efficient use of filtering
technologies on edge switches.  His line works to offer time service to
others, as allowed packets are only to port 123.  This draft RFC would
require the external firewall to open all incoming udp traffic from port
123, and would require a stateful firewall on all machines receiving
that traffic.

He believes that as currently written, if people implement this by
default they will not be able to block unwanted traffic at the least
expensive place and could easily allow a bad guy to port scan you, if
the bad guy launched his port-scanning from UDP 123.  Therefore as
written, this proposal will *decrease* overall security because of how
it cost-shifts.

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!