[ntpwg] WG: Re: WGLC on Network Time Security documents (3 documents)

[[e-mail]]

Hi Miroslav,

> On Mon, Mar 07, 2016 at 05:06:10PM +0100, [e-mail] wrote:
> > Hi all,
> > 
> > according to our understanding of the symmetric mode we added the 
> > following language to the draft in order to describe how NTS protects 
the 
> > peer associations.
> 
> Thanks for looking into that. I've few comments. 
> 
> > First: We added section 4.2 "Symmetric (Peer) Modes"
> > 
> >       <section title="Symmetric (Peer) Modes">
> >         <t>For the symmetric modes (active/active, active/passive), 
NTS 
> > works
> >         as it does for the client/server mode, except that both 
> > participants
> >         have to save state information. The participant who first 
sends a 
> > peer
> >         message takes the role of the client, a participant who first 
> > receives
> >         a peer message takes the role of the server, except that it 
keeps
> 
> This is an interesting approach.
> 
> For ephemeral associations I think the server/client direction of the
> NTS association is clear. But for persistent associations, what if
> both peers send packets before receiving reply from the other peer?

This depends heavily on the behavioral policy of an NTS participant who 
has sent request for which are as of yet unanswered.
There is not yet any specification text targeting this.

We are thinking about adding such text, in particular we feel that there 
are at least two obvious approaches: 
1.) "Any sent request starts a process waiting for a response. Any 
incoming message from the intended communication partner which does not 
represent a valid response ends this process and communication must be 
restarted. The process also ends when a valid response is received, or 
when a timeout value is reached."
2.) "Any sent request starts a process waiting for a response. This 
process is only ended either when a valid response is received, or when a 
timeout value is reached." (Implicitly saying that any incoming message is 
treated independently: if it is a request, it is processed as such and 
perhaps answered, if it is a response, it either represents a valid 
response to a pending request, or it is ignored and dropped.)
Currently we feel that the second approach is better for most cases.
In the particular case of peer mode with both peers sending requests 
before receiving replies, it might lead to two associations where only one 
would have been necessary, but this would be a rather benign error.


> What should happen when one of them is restarted, is the NTS
> server/client direction allowed to switch?

Yes, it is. This goes back to what I discussed above.


> 
> >         additional state to strengthen the security guarantees it
> >         receives.</t>
> >       </section>
> 
> An issue I pointed out earlier and that I'd like to see the NTS
> implementation in NTP to address is DoS attack on symmetric
> associations. The NTS association should be able to form and continue
> to work even when an attacker is sending spoofed packets to the peers.

We agree.


> 
> To allow that, I think the peer in the server NTS role shouldn't
> keep or update any state [until...]

We agree. We believe the specification to be consistent with this. If at 
some point it is not, please point this out to us.


> [...] and should respond to all packets from the
> other peer immediately as if they were client mode packets until it
> can save the KIV of the other peer and is ready for time_* messages.

This is tricky. We agree that this would be desirable. However, we think 
that the question of when a response is sent is not regulated by NTS so 
much as it is by the underlying NTP implementation. Since we wish to avoid 
any instances where our specification makes changes to the behavior of 
said underlying implementation, we will probably not add any text about 
this.

> That is also the point when ephemeral associations should be created.

I do not fully understand what your meaning is here. But as far as I can 
grasp it, the answer goes back to the point directly above: this would 
need to be regulated at an NTP level (I believe you would like to prevent 
NTP from creating an ephemeral association before NTS has performed 
authentication/authorization and determined that it will now keep state?).


Best regards,
Kristof

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg