Subject: Re: [Ntp] Rate limiting: DDoS, KoD, Pool, NAT

From: Philip Prindeville <[email-masked]>
Date: Mon, 7 Dec 2020 18:31:25 -0700

> On Mar 3, 2020, at 10:41 PM, Hal Murray <[email-masked]> wrote:
> 
> 
> [email-masked] said:
>> That kind of explicit client-tracking will get some of the IESG folks up in
>> arms.  I tend to agree with them. 
> 
> Thanks for the heads up.
> 
> In the normal case, the IP Address in the cookie would match the IP Address in 
> the packet so there is no information leaked.

What about port-forwarding to a server behind a NATting firewall?  I.e. 45.33.216.244.

-Philip

> 
> The interesting case would be when the client changes its IP Address and then 
> uses an old cookie.  Can the client reliably detect when its IP Address 
> changes?  Even if that works, it feels like the sort of thing that is likely 
> to break when somebody makes an innocent change to some unrelated code.
> 
> Even without an IP Address in the cookie, just using the same set of servers 
> from a different IP Address is giving a lot of info to trackers.  If you are 
> using the poop, an obvious fix for that is to discard all current pool servers 
> and do a new DNS lookup.  That also fixes tracking by looking in cookies.
> 
> Does it matter if the IP Address in the cookie is encrypted?  That doesn't 
> help if you are worried about the NTP server tracking you, but it does make it 
> harder for the bad guys who are watching traffic in the middle of the internet.
> 
> Where do the anti-tracking people hang out?  Is there a mailing list?  WG?
>

---

From: Hal Murray <[email-masked]>
Date: Mon, 07 Dec 2020 18:28:02 -0800

[Context is putting the requester's address in the cookie so that a bad guy 
can't get cookies from a server and then use them to DDoS somebody by 
reflecting off a NTP+NTS server.]

[email-masked] said:
>> In the normal case, the IP Address in the cookie would match
>> the IP Address in the packet so there is no information leaked.

> What about port-forwarding to a server behind a NATting firewall?  I.e.

I don't see any information leaked.  The NTP server doesn't know it's a NAT 
box.  The NTS-KE step would put the address of the NAT box into the initial 
cookies.  When the cookie came back from the NAT box, the address would match 
and the returned new cookie would have the same address in it.

If the client got a new IP Address via DHCP or whatever and was still behind 
the same NAT box, things would keep working.

----------

The case where that would get leakage would be when the client goes from, for 
example, work to home.  If it uses work cookies from home, the server would 
drop the requests due to address mismatch.  That would happen with/without NAT 
at home or work.  If the server logged that mismatch that info could be used 
to track somebody.  If the server drops the packet without logging the info is 
gone.

There is potential leakage from statistical counters.  If you can watch the 
counters you might be able to correlate with the packet that just arrived.  
But if you can see the arriving packets, you can probably see the lack of 
responses.  The IP Address within the cookie would be encrypted so seeing the 
packet on the wire doesn't tell you where the cookie came from.

----------

Your question actually says "server behind a NATting firewall".  The answer above was for the case of a client behind the NAT box.

I don't see any leaks if the server is behind a NAT box.  Do you have anything in mind?  I don't see any way for the client to determine that there is NAT involved.

Autokey didn't work through NAT boxes.  I never got far enough with Autokey to understand the details.  I assume an IP Address was tangled in the crypto.

NTS and shared-key both work and are well tested through NAT.

-- 
These are my opinions.  I hate spam.

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 8 Dec 2020 10:38:55 -0700

> On Dec 7, 2020, at 7:28 PM, Hal Murray <[email-masked]> wrote:
> 

My point was that the address stuffed into the cookie/nonce would mismatch the address in the source address of the IP packet once it got SNAT’d.

It sounded like you were tacitly counting on the two being a match.

-Philip

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Hal Murray <[email-masked]>
Date: Tue, 08 Dec 2020 10:03:55 -0800

[email-masked] said:
> My point was that the address stuffed into the cookie/nonce would mismatch
> the address in the source address of the IP packet once it got SNAT’d.

> It sounded like you were tacitly counting on the two being a match. 

I think it works, but maybe I'm missing something.

Server behind NAT box:
  Server gets clients correct IP Address which goes into the cookie.
  When the cookie comes back, it has the same IP Address and matches.

Client behind NAT box:
  Server gets address of NAT box.  That goes into cookie.
  When the cookie comes back, it has the same address (NAT box) and matches.

Note that "IP Address" in the above does not include the port number.

I think the key idea is that both ends don't have to agree on what the IP 
Address is.  The server both inserts the IP Address into the cookie and checks 
it when the cookie comes back.  As long as the packet comes from the same NAT 
box things will match.

If there are multiple clients behind the NAT box, one of them could use his 
cookies to DoS another system behind the same NAT box.

---

From: Philip Prindeville <[email-masked]>
Date: Tue, 8 Dec 2020 12:44:49 -0700

> On Dec 8, 2020, at 11:03 AM, Hal Murray <[email-masked]> wrote:
> 
> 

Not necessarily.  Most services are oblivious to the fact that they’re being NATted.  I don’t think this should be any different.

---

From: Hal Murray <[email-masked]>
Date: Tue, 08 Dec 2020 13:51:29 -0800

[email-masked] said:
?> Client behind NAT box:
> Not necessarily.  Most services are oblivious to the fact that they’re being
> NATted.  I don’t think this should be any different. 

Sorry.  We aren't on the same wavelength yet.

The client is behind a NAT box.
When the server gets the request, the return address will be the client's NAT 
box.
That's what the server puts into the cookie.
The server doesn't know that the packet came from behind a NAT box.

---

From: Christer Weinigel <[email-masked]>
Date: Thu, 17 Dec 2020 15:36:20 +0100

> The server doesn't know that the packet came from behind a NAT box.

Doesn't that break one of the features of NTS?  Quite a lot of the
complexity regarding cookies is there so that a client should be able to
change its public IP address and continue querying the NTS timestamping
server without having to restart the NTKSE process and retrieve a new
set of cookies.  Putting the public IP address in the cookie would make
that impossible.

  /Christer

---

From: "Dieter Sibold" <[email-masked]>
Date: Thu, 17 Dec 2020 19:31:59 +0100

I agree with Christer
Dieter

On 17 Dec 2020, at 15:36, Christer Weinigel wrote:

>>> Not necessarily.  Most services are oblivious to the fact that 
>>> theyâ€™re being
>>> NATted.  I donâ€™t think this should be any different.
>>

---

From: Hal Murray <[email-masked]>
Date: Thu, 17 Dec 2020 12:19:01 -0800

[email-masked] said:
> Doesn't that break one of the features of NTS?  Quite a lot of the complexity
> regarding cookies is there so that a client should be able to change its
> public IP address and continue querying the NTS timestamping server without
> having to restart the NTKSE process and retrieve a new set of cookies.
> Putting the public IP address in the cookie would make that impossible.

Correct.

The context was verifying that a packet actually came from the return address 
so that a NTP server couldn't be used as a DDoS reflector.  Without something 
like a cookie tied to the IP Address, I don't see how to tell a busy NAT 
server from a DDoS attack.

Does anybody have other suggestions?

We could invent a TCP protocol to distribute a lightweight cookie.  It 
wouldn't need TLS.  That feels like a lot of complexity for minimal gain.  We 
may learn more as NTS traffic grows.

If the usage pattern is home-office, and both DHCP servers have an idle 
timeout that is long enough so that the client normally gets the same IP 
Address, the client could cache cookies for each active IP address.