Internet Engineering Task Force 105, 22 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF105-NTP-20190722-1550

Description

NTP meeting session at IETF105
2019/07/22 1550

https://datatracker.ietf.org/meeting/105/proceedings/

A

I didn't even look at the check.

B

C

Okay, I think we are about ready to get started. I.

C

See we have a bunch of remote people and they seem to be able to hear.

C

Okay, as a reminder to those who are remote, you can get. We do have a in the Medeco interface, there's a way to jump into the virtual queue, and you can speak your questions as opposed to typing them in jabber and with that I know, so we can go ahead and so, first of all welcome to the NTP working group.

C

This is the IETF note. Well, you will have seen it before. There are a number of policies to which we ask you to adhere, and this is also our IPR regime. So everybody, if you have any questions, feel free to ask. If you're not familiar with it, you did, you did actually acknowledge it when you registered as well. So anyway, that's the note. Well, this is our agenda for the day yeah. We have a second page, the agenda, so the first thing we're going to do is agenda bat.

C

Well, first of all we're going to do a minute taker I know we have at all has agreed to take minutes. Do we have a jabber scribe, I thought that might be the case. I saw you sign in so rich has agreed to be the jabber sky, and at this point we're going to do agenda bashing. We had a bunch of ntp related topics first and then, after that we had sort of some tick-tock stuff.

C

Even though this was the NTP working group, because to sort of remind everybody, our intention is to finish the enterprise profile and to close tick tock and create a single time working group so that we have all of the time resources in one place, because that's effectively what we've had for the last several years anyway, I have had a request to sort of swap the tic-tock stuff with the ntp stuff, so that for somebody who will be arriving a bit later so so we will start with the tick tock stuff.

C

As far as the tick tock working group status goes, we do have one document, the enterprise profile and it is ready to go to the iesg. We currently between the two working groups have four documents: queued up and ready to go and and I have discussed this with rush and they will be coming out post with.

C

So the next two items you can do them in either order you would like Doug but would be for you.

C

Are there any other agenda bashes by the way? No okay.

D

You can come up here and do.

E

Some Doug Arnold on Vice Chair of I, Triple, E, 1588 I, don't know just give you a quick update where that at we've we have a draft revision, it's going through sponsor ballot and recirculation, and we have some comment on the recirculation which may or may not force us to do another recirculation we're meeting this week to decide that, if not, we will go right to publishing they would probably get out by the end of the calendar year.

E

If we have to do another recirculation, maybe you'll get out by the calendar year, we would do a whatever the minimum. One is so that's that's where we're at after that. We expect to be updating it with things that we had pushed off working more in the mode of actually 8o 2.1.

E

If you're familiar with that group at all where we will be doing amendment and core agenda on a much small, shorter time scale and then do a roll of provision every once in a while, so we'll be making changes right away on that any questions.

E

Okay, so I wanted to present us a number, some slides created by Steve green dirt at IBM and myself, mostly Steve, we're looking to create a secure profile for 1588, not sure where we're gonna do it yet, but we're just presenting it here to get some feedback. If possible, it will be a profile targeted at sort of enterprise.

E

You know single organization networks, mostly in the financial industry,.

E

But they're adamant they want something that has built in security.

E

So this is being driven to a large extent by regulations.

E

In the u.s. we have FINRA and theirs require that the clocks be maintained to 50 milliseconds, which really isn't that difficult. But you have to also law get him. You know provided records showing that you were have stayed in compliance and have audits, showing that you have some reasonable scheme for keeping good time and that sort of thing a similar requirement came out of Europe, which has a tighter time, synchronization requirement, 100 microseconds and a lot of firms, even if they're in the u.s.

E

do trades in Europe as well or if they're in Asia, they do trades in Europe and so they're gonna want to obey that as well.

E

Then there's also the players in finance who were doing faster things and they they have their own much much tighter timing requirements just for their own measurement system. Things like high-frequency trading going on as well.

E

So the data center in this case would be the data center for a bank or other financial type firm.

E

And so they have multiple sites, that's one of the things we have to account for, even though it's enterprise network it's it can be quite a big distributed even globally distributed network, and so there's some there to take that into account with whatever we come up with.

E

E

In timing, it seems, like security is always an afterthought. We had NTP just NTP and then it Auto key to try to add security and now we're we're improving that then we had PGP and all we had was some experimental annex conversion to that, no one ever implemented. So we don't really have security for that. So it's kind of an afterthought in the timing standards community, but not in for these customers there there are adamant. What are you guys doing?

E

I get calls from them saying this isn't not acceptable, so they really say it has to be secure. So it's it's a strict requirement.

E

Now there was there is some work that was done and it's going to come out in this revision that I mentioned before in 1588.

E

There's a discussion of approaches to security, that's in an informative annex and then there's there's also a TLV that can be attached to any PTP message that was defined, which we tried to make first of all enough to use various key exchange. Mechanisms that are anticipated might be used.

E

So these things are coming out, but they're not out yet and what is publish is just mxk that nobody uses. So it's pretty much useless at this point.

E

Okay, so, as I said, it's um a required practice in in this industry, and you know, and really in all industries and an increasing extent.

E

And so that that's really the impetus for this.

E

Impetus for this effort that we're starting is to address this. You know many many presentations and papers have been given on. You know the problems associated with insecure time.

E

Know, there's some other things that have come about talking to people in this industry that they're they would like to see one is we have to take into account that many of the PTP slaves will actually be just software running on standard hardware.

E

What what it has available in terms of hardware support will probably vary, and so it has to be of the work in the worst case, where it's just some server with no hardware stuff and time, stamping capability and you know, do the best you can I another interesting thing they brought up when I talked to some of these folks is we're already implementing several key exchange mechanisms. Can you please not make us do another one?

E

It's just for timing and not used anywhere else, so they would really like something standard that they already have implemented. That would make them happy and I'm sure there was some be some more things that come out as we get into this they'll say: oh it really. We really want this about that.

E

E

We're before with an effort to to draft something I, don't really have a profile to print to yet not sure, even where it's going to be. It might be here.

E

But some of the things that were suggested that we might think about because they might be helpful with security, would be if you had a network that could use peer delay, that's easier to secure, because a lot of the timing information is just exchanged on links from one device to another in a network that could support peer delay, which means every switch basically participates.

E

We might we might look at Tesla, which is you know, has been described in this group with respect to NTP, has been discussed with respect to NTP, so you're familiar with our help in PTP. We have the possibility to do to have a profile that requires two-step timing and that could make security much easier to implement. So that's something to consider.

E

We could say, transparent clocks are a real complication that we don't want to take on at this point, because the people who design them I kind of expect to be sort of altering messages as they go through and sometimes even in a cut-through mode, and that can be really tricky if you're trying to do hash codes and that sort of thing so so make. Maybe we won't take that on in the first place,.

E

Okay, so I'm just sort of announcing where we're getting started with this. If anyone's interested, you know, please contact its really quick registry. There we go, please contact me or steam kundo from IBM. We should be driving this and we're we're looking for input on what requirements are or, if you're interested in getting started. We can go ahead and try to craft something or at least get some ideas together and what-what PTP options we allow and not allow that sort of thing.

E

F

Hi doll Mizrahi, first of all, they're interesting, definitely something that will be interesting in this working group.

F

Just the general question: are you mainly targeting the financial market in terms of the accuracy and in terms of the applications that use Stein, or are you also considering other applications? We.

E

Would consider other applications if they have, if they're similar enough, but the people who are coming to us and saying we want this are from Finance of those of them. We're gonna tailor for their needs. If it works for someone else, that's great or if someone comes along and say, we also need it and we're similar enough that the same profile could work that we would include them. But so far we haven't heard from those folks we're hearing from finance that they want us. Okay,.

F

G

Let's do card anything to say about the white rabbit variant.

E

So white rabbit is very much of interest to the high-frequency traders. There's a lot of them are playing with it already, but for most of the customers who are coming to us for this, it's more for the regulatory compliance where they're talking hundred microseconds and white rabbit is a complication they don't need to take on at this time.

E

Any other questions yeah.

C

Just a second go ahead: Watson, hello,.

H

This is Lachlan live from Cloud Claire. You mentioned key exchange where you only want to implement one. Why not NDSU agree on keys.

E

That's an excellent question and we we we definitely would consider that you know we haven't got to the point where we're saying this is the one and I think I think it's a very safe bet that the people who will be putting this into their network will also be running. Ntp and they'll be wanting to run secure, NTP, so I think it would probably be very helpful to them that if those two lined up in terms of key exchange mechanisms.

I

C

Any other questions.

G

Let's do again go to the opposite end of the world, anything to say about PTP over extremely high variance links. You know, Wireless links.

E

No not really I haven't I haven't gotten a lot of feedback from network operator. It's about Wireless and PTP. I know people do it in sort of dedicated wireless links where both ends are sort of proprietary by the same company there there is. There is some work on the a toad I, Triple E 802 dot, one to support Wi-Fi and using their built-in timing mechanism, which is likely to have better hardware support than just TTP messages.

E

So they've developed an interface for that with expectation that will be used, but I, don't I, don't know how it fits in with this work. I think the people are looking to secure servers, which probably won't be on wireless, at least not in the near future, although eventually they might and wireless devices, you know, maybe handheld devices or laptops or something might just need NTP, and so they would get ntp over. Wi-Fi would be my guess.

C

Go ahead, Daniel.

J

So I continue to maintain that trying to cryptographically secure a protocol that only has has one way message transmission, so this would apply to both BGP into broadcast mode. Ntp is basically a duper enterprise because they're never going to solve the problem. Lay it X, whereas you have a quit, have a query response. Then you clearly unique identifier in the query and that establishes a time bound on the freshness of the response.

J

But if you're trying to a set of precision within 100 microseconds that wild, while that's more than you, that's that's more than you can expect to get with ntp over the Internet, that's easily achievable with ntp, where you're, typically, your time sources in the same data center, and if, if that's that, it's given that that's the only environment where PPP is practical begin with, why not just use ntp for this purpose.

E

So that's a good question: why not just use ntp? Because if you, if you pay close attention, you can get 100 microseconds with ntp with with standard equipment and implementations.

E

Maybe III think so. People who are asking for PTP are anticipating the future. Let's say: ok, it's 100, microseconds and but but the hft people are already turning around information and posting trades in ten microseconds, and so if the regulator's are really going to be looking for proper behavior they're gonna have to bring those times down. They originally.

J

E

It recently asked for a nanosecond, I I.

J

Mean I I think if you're I think, if you're trying to get to those levels, then you simply you yeah, yeah yeah, you simply need to be able to to have it have a trusted path between the bad between the sort between the source and the client I. Think, if you're on I think, if you're on any kind of adversarial network at all, like you're trying to get those positions, if you just don't.

E

Yeah I mean there. There are people, even high-frequency traders who use hardware timestamp ntp and they get quite excellent time transfer accuracies.

E

Nevertheless, there's a number of network operators who have come to us come to IBM saying we would like secure PGP, so we're going to give them that as well and III.

J

Mean if if, if, if you I mean I, if I mean if, if, if you have a customer, demanding it just to make them food just make them feel better with them with with no particular demands and what they're actually trying to accomplish then I did and then okay, I and I understand that I see that all the time I don't think. That's it! That's something.

J

If the ITF to consider I think if you're actually trying to solve problems, then then the answer is is is build the network, where you can trust your wires and don't do the crypto, because it's not buying you anything.

E

Well, I think if I look at, why why PTP is popular in a lot of industries? It's probably because the availability of things like boundary, clocks and transparent clocks.

E

And probably a greater availability of, say, n devices with hardware time, stamping, so that's that might be what's driving the desire to have a PTP version. That's secure as well as NTP.

C

Yeah I'm not sure we're gonna resolve this today.

C

I

Yeah, can you guys hear me I can.

C

I

Sorry, I don't have video available I'm, just yeah do to really reinforce untangles point yeah, there's lots of theoretical work and we've also seen it that says basically one-way or purely one-way. Communication has this drawback that then you pointed out you're always going to be vulnerable to delay attacks, um no matter what crypto you throw on the thing, um and maybe it would be healthy to not just think about as like the alternatives being do PTP with mostly or just one way or just use ntp, because PTP does support two-way communication.

I

um It's in its standard motor, that's just not the main source of data that you use for the actual disciplining of clocks, um but you.

K

I

A wired network and it's definitely possible to talk both ways and then you can get the guarantees um and also I know that at least Martin at Martin, Lanka and myself are working on prospects of basically combining a two way and one way approaches to to have like two way with security cover. This 100% guarantee of what offset you have at worst on and then being able to run like other protocols um in parallel, where you don't just go from from one to the next.

I

But you actually look at the the measurement results of both, and then you have this.

K

I

Basically, our fear for what you have such is probably and then for in what interval you offset is guaranteed to be, and maybe that's going to be helpful in this disregard, but also good, just something be done with a PDP profile. We're mainly are the two wave messages are used for for actual synchronization.

E

Well, PTP is usually used in a two-way mode like ntp.

E

But you know you raise one interesting point, which is: if you have a network where there's a some kind of two-way protocol, that's been carefully calibrated over some critical link, then that might be something that could just be used and other protocols can can initiate at the ends of that link. Taking taking advantage of that work. Well, characterized delays, I.

C

Think just to sort of wrap this up. I. Think the point is this: the revision of 1588 that actually includes a security mechanism will be coming out towards the end of this year and that's just sort of the beginning of this security work.

C

We will be there's an enterprise profile, that's ready to go to the iesg, and this would be would potentially be something like that for security. But there's a lot of you. This work is just starting, so there's a lot of opportunities and I. Think that there's a lot of synergy between the 1588 community and the ntp community and we're solving some of the same problems, and so the more that we can leverage each other the better off we will be so thank you for and if anybody has any further questions or wants to participate.

C

Please talk to Doug I'm kicking you out of the queue christoph okay.

E

C

Else: okay, so with that we're gonna go back to the top of the agenda and the first thing is I'm just going to do a really quick walk. We have.

C

The just a quick couple highlights of work that is been done. What I think at the last meeting, we actually announced that the Mac RFC had been published. So congratulations to onchao, and this time we can announce with great fanfare that the BCP has been published like last week so to to Daniel and to deter and to Harlan. Thank you very much, we're very pleased to finally have that off our plate.

C

We have three documents that are actually ready at this point: to go to the iesg NTS the guidelines for defining packet, timestamps and interleave modes, and now that we've cleaned out some of our of our chaff, we can move forward with those and.

C

Did I mention interleaved modes: I did yes NTS the guidelines for defining time stamps and the ntp interleave modes are all ready to go to the iesg with that we didn't do a face-to-face hackathon, but we did actually have a virtual hackathon this weekend with the with some folks remote. Were they going to speak to it or was?

C

Was Chris you're gonna talk or okay, it's Chris drama. Oh, he is on line there. He is so Krista. Are you ready.

C

I, don't know if he's actually just.

C

Are you ready to talk about the NTP hackathon? Are you can you get in the queue.

C

Okay, well, we will come back to him, I'm, not sure what the issue is, but they did Watson and Chester and Martin all worked over the weekend, actually Martin and- and so, if any of you all want to get in the queue and give a quick update on what you did that'd be great. Otherwise we will talk about it on the mailing list, yang.

L

Yeah hi everyone I'm trove I'll, give you a short update on the yang model. So next.

L

Yes, so we made an update between the two ideas, mostly editorial. We were given comments regarding the yang style guides that we should use more references describe the reference in detail, so we made that change.

L

We got a comment regarding the security consideration and explicitly highlighting that how the security of keys are taken care by the yang model, so we have updated that we are also using the NAC M technique, which is the net conf access control list, so IR, which we said the NAC M default deny so that the part which we don't want people to have access to, such as keys modifications that is hidden by default.

L

So those are the main changes that we have done and done a little bit formatting the based on what is the RFC style guide, with respect to tabs and and all the other things that you need to take care before your documents can be sent to I see. So we got some comments from Watson. So thanks for that, one of the things we wanted to explicitly discussed in this face to face is currently the NTS is not part of this young model.

L

Now, among the authors, we thought that it's better to get what we have right now out of the working group and anything else and new work anyway, will continue and we will use the augment mechanism of the base model to add new features, and it could it's perfectly fine for them to be in a future document, but we can get what we have right now, which is in a pretty stable space and publish it.

L

So that's the feeling of the authors, but we want to know what the working group agrees with this or or not, or whether NTS we should wait and add NTS into this model itself. So that's what's one of the key things which I wanted a feedback from the group and if the group doesn't care, the authors have a feeling that we want to publish what we have right now.

M

So personally, I think it should be there yeah.

H

M

I, don't think it's like a serial process right, so you don't have to wait for any has to be done to start incorporating things in there. So just do the stuff in parallel and I can hold the document somewhere up the line for the references right so I don't think it should be an issue like we can still go through the whole process, like other things and then, when oh those who's trying to kick it out and then, if something changes we can take care of it after right.

L

That's how I think about it. The only thing is maybe, from the author's point of view, I think the authors are little in the work: let's go otherwise you'll keep adding us keep making us wait for new new features. So that's still feeling but, like you want to do what what's right. At the same time,.

C

L

C

Separate piece right I mean the implementations, have sort of separated the NTS server from the ntp server, so they're sort of to implementation, wise they're, two separate pieces.

M

This probably don't ever coexist right, so I'm just saying like if there's enough commonality them like, we should do. The right, like as I said like do the right thing right, but if there's nothing in common like go ahead right, but I'm sure there's like a bunch of stuff in common that you're either gonna like redo or, like you know, probably miss it right like something like that. Well, I'm, not sure like how we want to do this like. If you want to skip it too later like oh, you know it would use team amount.

M

Is that what you think basically.

L

Whatever is the common grouping, whatever things that we can use, we will use, and if it's needs to be implemented separately, it's better belongs in a separate draft, so I want to know more opinion more feedback. What's the right thing from the group as well.

M

C

N

I trust you can hear me. Yes,.

C

We can hear you cool.

N

So the two questions I have are: has a reference. Implementation of the yang model been done yet, and is it possible to use any of the existing NTP authentication schemes with yang, as in the existing private key model? I.

L

Think the the private key part is there, Auto key doesn't exist and NTS is also not there. So only the basic, the key configuration thing is there in the model and with respect to implementations, we had done a very simple, nothing that we can ship right now, but just to make things working some tests internally, but we cannot say that we have a vendor implementation either for this model. Yet thank you.

M

Like I'd, like you know, want a break or something just go for it like just get it down, send it off and I. Just don't want to do abyss of this right. No.

D

It's definitely never gonna, be the.

M

L

M

L

To be augmentation or a scheme amount or something, never it's not going to be abyss.

C

Harlan you're still in the queue did I. Did you get back in or did I forget to push the button you.

N

Forgot to push the button excellent.

C

L

C

C

Yeah, it's not there yet.

K

C

Back to the yeah, let's do whatever is after the yang and I'll get this upload.

C

Alright, port randomization Fernando, you registered a oh okay, so you're in the queue did you register as a remote presenter or as a oh. Let me give you that Prelude, yes,.

O

Go ahead, okay, so I'll be presenting the draft on pole randomization in NTP version for next slide. Please!

O

So as an introduction to this document, I will switch off video because maybe it's better for him for the network. As an introduction to this document, it's essentially a document that updates the various entities specification so that NTP clients employee for randomization Fernando we're having a bit of an issue.

C

It's a better now.

O

C

It's better now go ahead. Okay,.

O

So essentially, this document updates the base NTP spec, so that it employs poor randomization for NTP clients.

O

This document essentially puts the inspect in line with BCP 156, which is a PCP produced by the transport area on transport protocol, poor randomization, the base NTP specification essentially suggests that NTP clients, employee the NTP service, port 123 for the local port, and this has a number of implications. For example, it makes blind attacks against NTP easier.

O

It hinders distributed denial-of-service mitigation because it's not easily to tell NTP server versus NTP client, packets and, of course this is a requirement that cannot be complied with when you have multiple NTP clients behind and not because of. Obviously, you cannot reuse the same port number for the multiple clients.

O

Most NTP implementations already do this, because essentially they rely on the underlying operating system for picking the TN side port and since nowadays, most operating systems employ transport protocol for randomization. Then this means that all of these NTP implementations benefit from that next slide.

O

So this is essentially what this document does. It recommends poor randomization on a pair Association basis. I spell out this thing clearly, because at some point we were discussing whether to do randomization on a per association or a per request basis, but this is the most recycle server tip.

O

Take it's not that we have closed the door to randomize in on a a per request basis, but this is the you know the most conservative take and the document formally updates the NTP spec, obviously, is so that you know this is a the default choice for NTP clients next slide.

O

So from an author's point of view, we wonder if the NTP working group wants to take this document as a work work and go buy them. So it's our question to the chairs on the working group.

C

Okay, there's been a Fernando, can I ask you, do one more thing that I know there's been a fair amount of traffic on the mailing list about this? Can you just summarize what what you believe the traffic on the mailing list has been yeah.

O

There have been essentially any two things, so some of the comments essentially were that if you do poor randomization on a per transaction basis, then that might have issues on the calculation of the time synchronization, because packets might go through different paths.

O

That's why this version of the document essentially has taken the most conservative approach, which is randomizing on a per Association basis. So that's one of the things. The other comments that we have received I think they were from Dunning was that well, these doesn't completely eliminate like blind attacks or that there are other mitigation for this, and our response to that is that poor randomization is a mitigation against blind attacks, are at the transport layer, so you can do anything else on any other layers. In fact, you should these control measures are essentially orthogonal.

O

That means there are things that you can do at the application layer like NTP us, or there are documents proposing that, but this is orthogonal to that. You know whenever you want to perform blind attacks against a protocol. Well, there are a certain number of values that you need to guess or know. At least IP addresses our transport protocol, port numbers and obviously one demise in the you know. Port number on the client side, of course increases the difficulty to perform such attacks.

C

Okay, obviously we will need to take this to the mailing list. Eventually, are there any comments today about adoption of this draft.

C

Okay, we will, let me do it another way. Is there anybody opposed to the adoption of this draft hmm anybody in favor? Anybody will read it if we actually adopt it. What.

C

Too many questions I'm being corrected by already.

A

C

Go ahead, Watson.

H

And fried comments, I, support, adoption and I think we really do need this mechanism for loss prevention, among other things, okay,.

C

Excellent, so we will take the call for adoption to the list, so I'm gonna go backwards in time briefly to the hackathon, since juster can't get to the mic. I'm just going to point this out, I've uploaded it as I've uploaded it to the materials page. So it's not really a slide and I. Clearly, don't expect you all to read this at this point, but basically the group of them worked for two days over the weekend and I can't see that myself.

C

So I have to look at my version here, and this is basically the test results of how far they got and what they tested and I.

C

First of all, I would like to thank everybody who worked remotely I know, especially the guys in Europe. You guys were we're working fairly late on this, and so, if everybody would take a quick look at that and see where we are, and if this seemed to be fairly useful, I think it would be useful to have a conversation on the mailing list about whether to do another.

C

One of these again I know the next IETF meeting is actually in Singapore, which time zone wise is is pretty challenging, but maybe we can pick another time or another date if this is useful to do the other thing that we talked about I mean we had previously discussed setting up a mailing list, I set one up, but we never actually used it specifically for implementation. Discussions I.

C

Think at this point, implementation discussions are, you know the ntp mailing list is generally not so overcrowded that we can't have those discussions on the ntp mailing list as well, but we also used a slack channel I, don't know if a slack channel is useful going forward for folks to you know, discuss implementation, testing questions whatever.

C

So will will ask that question on the mailing list as well, but thank you to the to our completely virtual hackathon team, any other questions or comments on the hackathon stuff, I will say it's really made a difference on it on helping us make get critical mass and move NTS forward. So I think it's really. It is very key. All right next was.

C

On implementing time, so next is on chow.

P

I, don't have any slides on it, because there is no major change from the discussion that we had in Thailand.

P

There was no comments to be addressed. There was just a minor negligible change in the POSIX section that that's mostly the editorial changed that there was um I, don't think there was anyone who was against the adoption of the document. So I guess that's the question.

C

Did anybody have any questions or comments on the adoption of the document we're there.

C

C

So we're basically getting like four or five documents out the door and then four or five documents in the door is.

P

That a good thing or a bad thing, I think.

C

It's a good thing: it shows some sort of progress all right, so there's no questions or comments. So thank you to Angela and Wilhelm for the the update of this document and we will look at adopting it.

C

Next was rough time. Yes,.

P

So I don't have slides for either that too, but after the last discussion at the IETF and the in Prague, we have updated the rough time draft choice and with two major changes, one is in the timestamp section. We have added the modified Julian date format for the timestamps and the second change was about the delay, attacks that how does rough time handle delay attacks and have updated that, based on the text contributed by tile. Thank you to all for the contribution.

P

There were other structural and language changes that was contributed by Marcus DNS of Marcus by Marcus I. Don't know how to pronounce his last name. Sorry, based on his implement an experience he wanted some clarification for the text and language, so I made that in the last update of the draft- and there were as far as I believe no outstanding issues. If anyone has some comments or suggestions, um you can see now.

C

Questions or comments on the rough time draft is anybody in here read this draft Oh excellent? How about how many read the implementing time draft know a little bit better excellent, no remote questions on implementing comment on the rough time.

C

H

Watson, okay, it's one of the co-authors of the rough and draft we are currently working on or I am currently working on, reconciling the pol with the rough time estimates um if people have an actual use case where this is necessary, please let me know because otherwise, it's quite a bit of work for applications like taking a checking whether these certificates- you don't need this, so please, let me you know if people have ideas of implementation and application areas, that would be useful in guiding the future evolution. Thank you.

C

Okay with that I.

C

Guess we have nothing, no questions franchise, so thank you. We will work on adopting that. Okay, thanks.

C

The next one is a.

C

Draft well, net meta can talk to it. I think we've only seen meta remotely before so I.

Q

Don't know I I was here. Oh that's,.

C

Right, you were here a year ago, I forgot about that. Have we've seen you remotely since.

Q

So hi, I'm, Nana and and I want today to a present very briefly, a horse, a a mechanism for ntp and the updates that were made. Based on the comments that we got for a working group. Adoption next slide. Sorry, it's a John work with their Danny to live, tamazaki and massage appear. So the short reminder is- and we consider this this rich mana, but we assume that the attacker have fully control of a large function of the NTP server. It's a quarter.

Q

We somebody is capable of both designing yes and determine when the response is going to advance and, of course we assume that is malicious and try to shift declines time as much as possible and makes like. Please ensure each reminder of their solution sure. So, on the one hand we rely on many NTP servers. We generate large pool of NTP a hundred of servers to a plan, but on the other side we choose at random only terms of them in order to avoid overloading the NTP servers.

Q

And finally, we use a smart filtering in order to remove outliers and make the heart attack here to contaminate their chosen sample and next slide. Please. So so far we got comments on two topics. The first one was that we should decide. Where were you how we want to use harness to enhance and TP security and whether it will be externally and today and to be all within the within the NTP?

Q

So in 1201 we added a he brewed approach when we say that when precision and currency are critical, then basically by default, use ntp V for updates and array when a threat or evidence of attack detected based on horn samples, then you can use a long time instead, and the other topic was that since Hannes use great authority of the sample site server over time, so maybe it can cause adverse very effect on precision and constancy.

Q

So in rough future we evaluate the dis effect, a both on precision and in currency in different location, both in Europe and in the US, and we found that home says fair precision around three milliseconds and thumbs up dates are close to and to the average NTP updates and up to two to three millisecond gap.

Q

Next slide, please so so far we have updates and draft based on all the comments that we got and and of course we continue a evaluator, honest performance and security and for different attacks at different location in the world, and we believe the songs draft is ready for working group adoption.

Q

A

A

Q

Good questions, so we we assume that for now it's Ananta cated because we don't have authentication yet, but we assume that the concept of course and query many servers can be still exist and we can still benefit it. Even when we are talking about an authentication servers.

C

Okay, any other questions.

A

Q

So we consider a man and me we talked about men in the middle, but basically we assume that it's a a much more sophisticated, a attacker that they have control over the servers, which means that we want to recognize it. The eddies attack by authentication.

Q

Is that answer your question? Okay,.

K

C

B

C

I can't first that.

A

That's a pretty big assumption. What you're, assuming that the.

A

Q

Want to be- and we want to be able to co-op with a more sophisticated attack carrier- is so I think it's I, think essential and and of course I am. It can also and chuckle a delay tax and other things that that authentication servers won't be able to to detect.

C

Anything else from oh there's, one more from Harlan rich.

A

A

Lots of servers- oh.

K

A

Q

Because we're trying to be the this to create a safer environment that you can so, of course, we you can say yeah one D probability that would the attacker would have and we'd have this kind of control of a large function of the identity pool. But it doesn't mean that we don't want to consider it when we, when we want to create a new mechanism and that cooperate does so.

C

Okay, did you do you want to say some yeah.

M

Suresh Krishna, so like one thing that like I like about this, is like one of the things that has changed in the Internet. Is the threat model itself right? So if you start from 3552, we always assume the communication channel might be compromised, but the endpoints are usually not right and and I think the IAB has started some kind of work on this thing to actually redefine this, so I think it's like a timely thing.

M

Like you know, you don't know how that's gonna go like the, how they be that model update, is gonna, go but I think it's in the same kind of category, so I think I'm supportive of the work personally so I think it's good. Thank.

Q

A

Jabber Danny Meyer says this might be useful if ganged with an NTP server again, can it so hide together with an int it might be useful, tied together with an NTP server. Jenny says it might be useful. um It's my sure, I understand this comment. Just relating the exact words, maybe can even explain a little more.

C

Yeah he hasn't typed anymore in here, and it's not okay.

Q

So what I can say is that, in order to make it more deployable, which right you to come up with a mechanism that it relates to the client and may be modified it for will really timing modifications.

Q

Of course, we can maybe benefit from using or modified the NTP servers, but then I think that the deplorable will be much harder, so we are looking at it. This is one of our of our further research topics. Actually so, okay.

C

Any other questions so I think we will take the this adoption discussion to the mailing list. So thank you. One other thing I wanted to noted. If those of you haven't looked at the a NRP schedule that not the the IRT F open meeting tomorrow is featuring as it does every time one or two of the a NRP Prize winners and Netta is one of the Prize winners and she is presenting this work there tomorrow. So it'd be interesting to see what the with the broader community thinks and so congratulations to you and I.

C

Imagine several of us will show up to hear you, but I am interested in seeing how its received by the broader IETF community as well so.

C

Okay, the so at this point we've covered all of the documents that were updated. I think we have a number of calls for adoption that we need to do. We have some that we haven't done yet for existing documents and we also have.

C

A document we need to send out I believe it's ready for working group last call I'm, not sure it's the ref ID document. The last time we talked, we said we needed to pull the leap, smear stuff out, that's been done and I was looking at it again and I believe it's probably at this point ready to go, and we just haven't done that I, don't know Harlan if you had any planned updates to that or if you were ready to send that for working group. Last call.

C

Should be ready to go okay, great and then I know that we have some extension field Docs that we didn't send out for adoption, as I said, we're clearing our plate of a bunch of existing documents and we'll get to work on the additional documents.

C

At this point, we have reached the end of our agenda. If does anybody have any other business? Oh.

C

So Suresh, can you hold up the blue sheet? Is there has everybody in the room sign the blue sheet? Okay, so we pass that around again, so folks can sign it and I think that brings us to the end. We sort of wrapped up a bunch of at the process of wrapping up a bunch of work. That's been on the table for a long time, which is kind of a good feeling once we get it actually wrapped up.

C

So any other questions. Well, oh, wait. I.

P

Maybe I missed it, but did you mention, did a minimization draft? What's the status for that I didn't think? Oh.

C

Yeah, that's on my list. I skipped right over it, so that we believe the status of the data minimization draft is that it was it's gone to working group last call and we were waiting on one set of comments. We haven't received those comments and so I believe at this point, and we need to a quick review of the mailing list ourselves just for our own sanity, but I believe it's ready to go to the iesg, so yeah I mean was that the I mean, as I recall, that the the current draft represents everything.

C

So this is so I'm guessing Harlan that you can't you you don't have audio right. That's why here? Okay, so in the in the oh, he is oh, okay, excellent!

C

Go ahead! Harlan I.

N

Don't believe I've received any responses to the objections I've brought forward on the data minimization draft.

C

So this image, I'm gonna, speak Rancho real briefly. This is where we might. This is what I said. We need to review them the mailing list, because I thought that we were at this stage where we were waiting on information from new Harlan, sir I did.

N

Not understand I did not know that. So, if I, if you are waiting on information for me, I'll have to go figure out what it might be and then take care of it all.

C

Right so maybe the thing to do is to have a small conversation with the data, minimization authors and you, and maybe the chairs and figure out what pieces were missing. But when that dinner and I were talking earlier today, we've thought that it was something we were waiting from you for so I mean.

N

I, don't have any new information, the objections I've raised, I've done before and I, don't know what new information you could want about them. But, okay.

C

I think we're gonna have to take this offline Harlan because there appears to be using between at least the chairs. So so so we'll set up a side conversation with with the parties involved here, but our understanding was, it's been through working group last call and the the objection that we had. We had one objection on the table. So that's that's the answer she original question on Shaw, which is what's the status of that draft.

C

So all right so way forward is the last thing. I did recall that I there was one other thing I want to talk about. We do seem to make a little bit better progress when we do virtual interims, so we will be planning some virtual. You know one maybe two virtual interims between now and the Singapore meeting, and we may try and plan some sort of a virtual interrupt testing event for NTS if that makes sense as well.

C

Any other comments, questions comments.

C

Excellent. Thank you very much and I give you some extra time back in your day,.

C

This has got to be one of the quietest rings. I've ever seen. Guys clearly did not do your afternoon. Coffee.