Re: [chrony-users] RE: Can we deny non-NTS client?
On Mon, Jan 16, 2023 at 04:41:49AM +, akihiko.iz...@sony.com wrote: > When chronyd failed NTS-KE handshake (ex. mis-configuration of certificate), > does chronyd fallback to plain NTP (or not)? No, that would be a major security issue. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
RE: [chrony-users] RE: Can we deny non-NTS client?
> The response is sent only if it's not longer than the request. In the source
> code it's in the transmit_packet() function in ntp_core.c:
I looked the transmit_packet() function and it seems to be called at sending
every NTP request/response.
I feel that's good and safe implementation. Thank you.
> > RFC8915 describes "8.7. NTS Stripping". Isn't is applicable to Chrony?
> chronyd as an NTP client configured with the "nts" option ignores
> unauthenticated responses.
When chronyd failed NTS-KE handshake (ex. mis-configuration of certificate),
does chronyd fallback to plain NTP (or not)?
(If it is true, I afraid dedicated NTS server/client may use plain NTP
unintentionally.)
Best Regards,
-Original Message-
From: Miroslav Lichvar
Sent: Wednesday, January 11, 2023 6:54 PM
To: chrony-users@chrony.tuxfamily.org
Subject: Re: [chrony-users] RE: Can we deny non-NTS client?
On Wed, Jan 11, 2023 at 02:31:11AM +, akihiko.iz...@sony.com wrote:
> Thank you for clarifying my question. I learned a lot.
>
> > it would not be sent as there is an additional check made before
> > transmission comparing the length of the request and response.
>
> What comparison is done between the length of the request and response?
The response is sent only if it's not longer than the request. In the source
code it's in the transmit_packet() function in ntp_core.c:
if (request_info && request_info->length < info.length) {
DEBUG_LOG("Response longer than request req_len=%d res_len=%d",
request_info->length, info.length);
return 0;
}
> > If the NTP server didn't respond to unauthenticated NTP requests, it
> > couldn't respond with NTS NAK to indicate the client it has expired cookies.
>
> I understand.
> I think sending NTS NAK is necessary for mis-authenticated NTP packets, but
> not necessary for plain NTP packets.
> Is my understanding correct?
Right. NTS NAK is sent only if the request contains the NTS-specific extension
fields and the authenticator is not valid (most likely due to the client using
an old cookie, which the server can no longer decrypt).
>
> I have another question.
> RFC8915 describes "8.7. NTS Stripping". Isn't is applicable to Chrony?
chronyd as an NTP client configured with the "nts" option ignores
unauthenticated responses. An NTS NAK is accepted only if no valid
authenticated response is received in the polling interval, i.e. an off-path
attacker cannot trigger a new NTS-KE session unless there is a packet loss
between the server and client, or the server cannot respond to all requests
(e.g. due to rate limiting).
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] RE: Can we deny non-NTS client?
On Wed, Jan 11, 2023 at 02:31:11AM +, akihiko.iz...@sony.com wrote:
> Thank you for clarifying my question. I learned a lot.
>
> > it would not be sent as there is an additional check made before
> > transmission comparing the length of the request and response.
>
> What comparison is done between the length of the request and response?
The response is sent only if it's not longer than the request. In the
source code it's in the transmit_packet() function in ntp_core.c:
if (request_info && request_info->length < info.length) {
DEBUG_LOG("Response longer than request req_len=%d res_len=%d",
request_info->length, info.length);
return 0;
}
> > If the NTP server didn't respond to unauthenticated NTP requests, it
> > couldn't respond with NTS NAK to indicate the client it has expired cookies.
>
> I understand.
> I think sending NTS NAK is necessary for mis-authenticated NTP packets, but
> not necessary for plain NTP packets.
> Is my understanding correct?
Right. NTS NAK is sent only if the request contains the NTS-specific
extension fields and the authenticator is not valid (most likely due
to the client using an old cookie, which the server can no longer
decrypt).
>
> I have another question.
> RFC8915 describes "8.7. NTS Stripping". Isn't is applicable to Chrony?
chronyd as an NTP client configured with the "nts" option ignores
unauthenticated responses. An NTS NAK is accepted only if no valid
authenticated response is received in the polling interval, i.e. an
off-path attacker cannot trigger a new NTS-KE session unless there is
a packet loss between the server and client, or the server cannot
respond to all requests (e.g. due to rate limiting).
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
RE: [chrony-users] RE: Can we deny non-NTS client?
Thank you for clarifying my question. I learned a lot. > it would not be sent as there is an additional check made before transmission > comparing the length of the request and response. What comparison is done between the length of the request and response? > If the NTP server didn't respond to unauthenticated NTP requests, it couldn't > respond with NTS NAK to indicate the client it has expired cookies. I understand. I think sending NTS NAK is necessary for mis-authenticated NTP packets, but not necessary for plain NTP packets. Is my understanding correct? I have another question. RFC8915 describes "8.7. NTS Stripping". Isn't is applicable to Chrony? Best Regards, -Original Message- From: Miroslav Lichvar Sent: Monday, January 9, 2023 9:42 PM To: chrony-users@chrony.tuxfamily.org Subject: Re: [chrony-users] RE: Can we deny non-NTS client? On Mon, Jan 09, 2023 at 12:15:23PM +, akihiko.iz...@sony.com wrote: > > chrony does not implement any modes that could amplify NTP traffic > > Thank you. > But I afraid NTP server is vulnerable to spoofed source IP address of NTP > client, it may participate DDoS attacks even though chrony does not amplify > NTP traffic (amplification factor is small). A reflection (amplification factor of 1.0) does not seem to be useful. If you can spoof the source address, why not send packets directly to the victim? At least, I have not heard of any DDoS attacks using a 1:1 reflection. If that was an issue, many other protocols could be exploited, e.g. TCP, ICMP. In any case, NTP authentication doesn't prevent reflection. It actually makes it easier as the packets are longer, so a single server would reflect more traffic (if it is limited by packet rate). -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org. -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] RE: Can we deny non-NTS client?
On Mon, Jan 09, 2023 at 12:15:23PM +, akihiko.iz...@sony.com wrote: > > chrony does not implement any modes that could amplify NTP traffic > > Thank you. > But I afraid NTP server is vulnerable to spoofed source IP address of NTP > client, it may participate DDoS attacks even though chrony does not amplify > NTP traffic (amplification factor is small). A reflection (amplification factor of 1.0) does not seem to be useful. If you can spoof the source address, why not send packets directly to the victim? At least, I have not heard of any DDoS attacks using a 1:1 reflection. If that was an issue, many other protocols could be exploited, e.g. TCP, ICMP. In any case, NTP authentication doesn't prevent reflection. It actually makes it easier as the packets are longer, so a single server would reflect more traffic (if it is limited by packet rate). -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
RE: [chrony-users] RE: Can we deny non-NTS client?
> chrony does not implement any modes that could amplify NTP traffic Thank you. But I afraid NTP server is vulnerable to spoofed source IP address of NTP client, it may participate DDoS attacks even though chrony does not amplify NTP traffic (amplification factor is small). > If the NTP server didn't respond to unauthenticated NTP requests, it couldn't > respond with NTS NAK to indicate the client it has expired cookies. I understand. I think it is a trade-off between spoofed source IP address and expired cookies. I hope administrator of the NTP server can select which of them. Best Regards, -Original Message- From: Miroslav Lichvar Sent: Monday, January 2, 2023 6:56 PM To: chrony-users@chrony.tuxfamily.org Subject: Re: [chrony-users] RE: Can we deny non-NTS client? On Tue, Dec 20, 2022 at 11:14:04AM +, akihiko.iz...@sony.com wrote: > I consider public NTS servers which serve to any NTP client. > I afraid NTS servers are abused for DDoS amplification. chrony does not implement any modes that could amplify NTP traffic, like the ntpd mode 6, mode 7, or Autokey. No matter how it is configured, it won't amplify plain NTP, NTP protected by symmetric key, nor NTS-protected-NTP traffic. Even if there was a bug causing a longer response to be generated, it would not be sent as there is an additional check made before transmission comparing the length of the request and response. If someone is claiming your chrony server is amplifying, they are wrong. I run a number of public servers and occasionally I get abuse reports claiming amplification, but their logs, when they actually have some, don't show it. They are just misinterpreting a busy NTP server as a DDoS attack. > Regarding RFC8915, "8.4 Avoiding DDoS Amplification", > > NTS is designed to avoid contributing any further to this problem ... > > So, I think NTS server should be able to reject non-NTS NTP request to avoid > DDoS amplification. If the NTP server didn't respond to unauthenticated NTP requests, it couldn't respond with NTS NAK to indicate the client it has expired cookies. This would slow down synchronization of NTS clients after being turned off/suspended for a longer periods of time. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org. -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-users] RE: Can we deny non-NTS client?
On Tue, Dec 20, 2022 at 11:14:04AM +, akihiko.iz...@sony.com wrote: > I consider public NTS servers which serve to any NTP client. > I afraid NTS servers are abused for DDoS amplification. chrony does not implement any modes that could amplify NTP traffic, like the ntpd mode 6, mode 7, or Autokey. No matter how it is configured, it won't amplify plain NTP, NTP protected by symmetric key, nor NTS-protected-NTP traffic. Even if there was a bug causing a longer response to be generated, it would not be sent as there is an additional check made before transmission comparing the length of the request and response. If someone is claiming your chrony server is amplifying, they are wrong. I run a number of public servers and occasionally I get abuse reports claiming amplification, but their logs, when they actually have some, don't show it. They are just misinterpreting a busy NTP server as a DDoS attack. > Regarding RFC8915, "8.4 Avoiding DDoS Amplification", > > NTS is designed to avoid contributing any further to this problem ... > > So, I think NTS server should be able to reject non-NTS NTP request to avoid > DDoS amplification. If the NTP server didn't respond to unauthenticated NTP requests, it couldn't respond with NTS NAK to indicate the client it has expired cookies. This would slow down synchronization of NTS clients after being turned off/suspended for a longer periods of time. -- Miroslav Lichvar -- To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-users-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
