Internet Engineering Task Force 101, 19 Mar 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF101-INTAREA-20180319-1550

Description

INTAREA meeting session at IETF101
2018/03/19 1550

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

A

Hello: everyone welcome to the interior, ietf 101, so we're gonna get started. We have a busy agenda this time.

A

So, first of all, not well I. Guess you've heard that there's a there's a new, not well, so please take a look at it. Especially there is a privacy policy at the end that we encourage you guys to take a look. That is a new addition to the node. Well, all the rest, pretty much the same as I said used.

A

Some reminders minutes are taken. Minutes are the meeting is recorded, your presence will be locked and we scribe. Please help contribute online to the minutes. We have the etherpad. Can we get some help from minute taker? Yeah?

A

Okay, so thank you very much Ian for helping, but please do help um whenever you can to get more notes or to clarify your points. If you see them jabber do you have do we have someone that can help us with the Java? Please thank you. Thank you perfect.

A

So, moving down to the agenda now we're going to give you guys a quick update from all the chairs in the ad on document status and some other topics. Then we have the presentation from Eric on the PVD IP tunnels, quick update from mark. If he's around, then we have a gooey generic UDP encapsulation from tom some presentation about iLab there, something there's going to be the debuff that we also have our quick heads up here.

A

That's going to be presented, then we we have the presentation about the privacy network address from Tom as well IP fragmentation from Ron toxics from Vladimir and availability of information in criminal investigations from David. Sorry, here this okay, could we increase the volume? Thank you very much, yeah, all right. So moving down to this working group status update, so the privacy considerations for i3 broadcast multicast protocols. It's now in the RFC editors q.

A

Re just a quick answer to the to the jabber. We did receive the slides from the presenters, their remote presenters as well so privacy considerations for IP broadcast and now it's an RFC editors queue so hopefully soon will become an IRC GUI. We have the presentation from that working group draft the IP over internationally partially partitioned links and that's a trap type expired and we encourage people to take a look for please. If you, if you have interest in this topic, send comments, make a review. That would be very useful for the author right now.

A

The the draft is stalled because we haven't had any any update on it and but we do need the community feedback if we want to advance that topic. So please take a look at that. One probe nights now: RFC 8335. So thank you very much. Congratulations there and IP tunnels in the internet architecture we'll get a presentation so moving to the announcements is Suresh in the room. Yeah thanks.

B

Isis krishnan area to do so. We had a like discussion in the iesg, so one of the documents that it came in through the independent stream- and it was trying to update like, are actually change, staying and document that was done here, which is the recommendations for logging with ports. So what we did in the IES G is like sent a note saying like don't publish this, because it needs to be done in interior because we published the original document. So that's the last document on the list over there, the draft divorce, eg and logging.

B

So this, like personally me I, spoke to the author and he was willing to present remotely the document and daddy has to see. Is the recommendations like in the RFC's he's talking about is like whether it's practical and how he can actually go about logging, the boats properly based on like, what's in the servers and everything so there's like this one, contains like a inventory of what's in the servers and what's being done?

B

What's not being done and some techniques in there so I would really appreciate if you pay attention to it and see like you know how we can update our PCB thanks.

A

Yep so so we'll make sure that we leave enough room in the agenda for that presentation. At the end, so Suresh said that is the the one on availability of information in criminal investigations involving large-scale IP address, sharing technologies, all right, so any bashing to the agenda.

A

Hearing none I! Guess we can move to Eric. Please.

C

By being here, okay, anyway, so compared to what happens last time, we got a big big news and we can show the next slide. If you don't know, remember, can the discussion whether we can get already anionic code point basically for the option we have now. So thank you to the chair and Suresh I. Don't know s Eurasia disappear. So thank you for this. It allows us to make a multiple implementation of sending this array option and receiving this array option to be compatible there and make more tests.

C

We use this number 21 and I think you know it's a fan answer with 21, but at least we got the number it's late right answer, 41 anymore anyway, it's like a guide is obviously not read in this room anyway, so we use this number for di cottan on this weekend. Next slide other change, so we make the things clear. There were a lot of section regarding using the PVD additional information. Remember it is. The G is on file that we are fetching to describe and the connection based on the bandwidth of latency.

C

For instance, we completely remove this from the text.

C

I think it's still valuable to F to use the PVD JSON file to convey some transport level information, but for this draft we remove it if we arm no interest later, let's plant for another draft and maybe another document there thanks to Bob, the document was a little bit fuzzy indeed, whether it was for the network layer or the application layer for the author, it was obvious that the JSON file that we fashioned after the array is for the application, but it was not in the text, so we make it clear that this additional information is for the application.

C

We even think to change the name into additional application information to make it very crystal clear: we try to improve the security and privacy section. Of course, mostly we can maybe improve it. We made a mistake in doing the padding. You know all the options in our ASO actually in any neighbor discovery. Message must be aligned on 8 bytes and we basically at the previous one, aligning on the four bytes so easy to fix. Last time in Singapore there was a huge amount of discussion about all.

C

Can we send different information to PVD, aware host and non PVD aware both so the authors? We got a design meeting in a nice room in Singapore we considered as an option such as using another specific multicast group to send this array to PVD away only at this weekend of dirty and a few other one. So we end up in an idea, not new code container. Next slide, you don't mind. So that's the new option and you see them in this option.

C

We can add at the bottom additional option, like Pio array of a row, deformation option prefix information option, a with other options that can validly exist into a route advertisement can be included into the PVD option, as we need as well sometimes to include options like MTU, which are not per se an option, but our feeling to the array header itself. We have the option based on the bid a to include yes or no, a repetition of the routing advertisement header. So we can add their next slide, so example look about this one.

C

This is the PVD ID option. It includes at the bottom two other option, this Rd at the NSS and the PIO. All of them makes for quiz 5 bytes, but 4, plus 5 times 8 bytes, the ID and the header with example, dot orc. There makes as well 2 bytes by 2 times, 8 or 10, so the full length is 12.

C

Okay, actually I counted at least three used it to make 12. So now we put 12 in the lines there, meaning next slide. A PVD aware understand deception. No, he is a duty to look inside the option, and now you know that okay, the a flag is not set. So after the name and the padding- and we know the name is finished because they are lengths right is the fully qualified domain name is expressed as a DNS request. Name, we have another option, which is our DNS s. We got the length of this one.

C

We go to the next one and so on so for p, video, where they will see not only the PVD ID. It is used to bundle all information together and present it to the application. But we they also got this our DN SS and the PIO next slide and non PVD aware do not understand the type xxi that we just receive.

C

So they say: okay, I skip it and the length is 12, so I'm going to the option, which is after so with this we can present Pio, aardeen, SS or whatever you want to PVD away oast, while the options outside of the container as simply use only by non p, video a host. Of course, an array can only contain if you want just the PVD ID option. Okay, that's not a problem! Next line implementation status, nothing has changed compared to Singapore.

C

We make progress on Nanak's, obviously next line and the hackathon as I said, we work together with two universities. Relation Aberdeen got some people from Cisco, but Kyle is well from San vine and another University. Three I forget wenching from three Campari Tech, and basically it was the mix of pvd's or 9x, a neat which is in another taps project source address, dependent routing because we like this and Cal port. It was done by acharya next.

C

So it has really all the piece we touch and all those piece were using the new ini code next, so we are not ready room class cold for sure, even if the implementation exists- and we are working for this for more than a year now, but I would love to get a service review by this group as well as I will ask later to six men and v6 ops, so review are really important. I mean modern.

C

Mp3, apply two questions, of course here and ring the week, but you can't commit to review this document and it changed any volunteer. Okay done, Ted, Michael and Yin I, don't know who's taking notes, but you can put this into our. Thank you. Don't forget to put your name right and for me that's it. That's all. I have to say today and thanks again for your support for Unicode.

D

Okay, I have a skip.

C

It is to know this. Okay, if you want okay, I prepare some slide is a backup in case I got the question right so go on next.

C

So we provide into the JSON file some information right and we use a specific, well-known URL. So if you know the name of the company, you can mostly guess the fully qualified domain name and guess the URL. It's well known right as on purpose, so you could download from everywhere this JSON file. So my advice is that don't put anything confidential here right because anyone can igneel access and you can also restrict the access on the web server hosting this JSON file to addresses that belongs to you.

C

Okay, working for Cisco I will accept only request from prefixes allocated to Cisco, not to say another company. That's one aspect next now, even if we provide a PVD ID, it could be something like example.org or whatever. It's just information right. We don't provide anything more anyway than array but think about a rock DVD I, don't know what it was really useful to do as Montana Tech, but we can F. As I said, the black ed we can have the JSON file.

C

Server can be a black hat guy, the network can be of style and the first device can be also hostile. So they can basically send you rogue route advertisement if a fake DVD ID or they can deliver to you, a fake JSON file with wrong information. So that's all we try to do it now. Next, so first one I am layer.

C

Two adjacent and I want to send you a packet, pretending a you are connected to cooperate, comma, a regard block it right, there's no more dangerous than anything, so problem solve as long as you run a decent network next slide. So now, in this case, the router is a bad guy, so you I not spot somewhere and the spot somewhere pretends to be again cooperate, or in this case good calm.

C

So what you do you try to connect to the JSON 5 server, and this guy is a wrong one as well right they affect you DNS and they figure the certificate. Oh, but you cannot affect a certificate right. So when you try and download the JSON file, TLS will refuse to connect, and if you have a look at configuration on the end point telling a I only accept PVD that retries the fetch of this JSON file.

C

Remember that's an option, but if you are configured to download this file- and you cannot get it because the TLS session is not established because the certificate is even valid cell sign or whatever you refuse- and you reject this PVD next so now another one where again, you are in hot spot, pretends to be good calm.

C

This time it does not pretend to be the JSON file server as well, so you can connect with a real SSL or TLS session and don't know the JSON file.

C

Now the thing we have in the JSON file a mandatory field, key which is prefix, which is basically in this case vb8 beef I, forget to put a slash for TX or in the slide. Now, when you receive it, you need to compare this covering prefix from the JSON file, with the prefixes you receive as API or in this case the Pio was including bed / 64 bed / 64 is not including in B / 48 will reject it.

C

Okay, so you need to deliver not only the write JSON file, but we need to deliver the right Pio. Oh I'm, a bad guy. I am allowed to do not next right, so now I am sending okay, no, not spot. I am sending you the array, good, calm. Okay, the flag is still there now I'm using the right.

C

Basically v6 address right, Pio I'm fetching the file JSON file, and indeed it would match right, because there is the route in the middle is doing NPT and nothing between the real good traffic's beef and the bed that is used by the attacker.

C

In this case, the protection is very simple again pretty much like the confidentiality. The server will only serve the JSON file to its own address and the request after being knighted or NPDES is coming from bed. So it drops the request. It doesn't receive the JSON file and again I'm configured to use only if there is a JSON file, I don't get it I refuse to use this PVD.

C

Next now we find a place and it's actually PA within the room. We find this, which is can intricate right. We can fool everything. Nothing is really secured 100%. What do we have? Now? We have a bad guy bottom left, which managed to get access to the real network, so his access in the beef, Network, okay- and you know that the PVD is good calm now with a companion somewhere and the victim is on the top left. The next router is sending a sending PVD.

C

The name is good calm and please use the address beef as well. Remember the big arrow Janel, whatever you want, is tuna right, GRE or whatever. Now the victim somewhere on the top left receive. Oh, is good calm. Let's do it. Let's connect to the server, and then this is the small line going via the dinner. That's rotting decision proxy by the bad guy in the good comm network that goes to the server.

C

The server sees a good sauce address is surveyed and to NSSL works, fine right because the right certificate right address, and then in this case the attacker is able to pretend is good calm but on your honestly, is already in good calm. So what can you do there right? So basically, in this case, we can do nothing more, but we never pretend to be a fully secure right. Pvd are here not to secure erase PVD, sorry to give you more information and the application layer, and nothing is the last 100.

C

Yes, sorry privacy. So obviously there is some minor issue. Is that when the goose boat would arrest even a PVD a wants to get information about it, it will basically go and fish the error right access, your elevator LS. So anybody on the path can know that this v6 address is trying to connect to this DVD right. It is thus nice in the clear you can even know who is there?

C

Okay, but what's different than all our device run now here going to captive that example.com or whatever your operating system use right now to detect. There is a captive Potter, it's even better, because normally when here all of us in the room, except some exception right, we do not go to our own cooperation to see what there is a captive portal right. We go to some other vendors, which is not Python the service providers or the user.

C

What indeed, when you use PVD you stay within one Operator, say or support, or whatever that's one thing, and we advise in the draft as well it as soon as you have used your ipv6 address to fetch this JSON file, you change of a pv6 address and the other one is no more no more used. You throw it away. That's basically, our status, a little bit fast, explained its little bit more explanation into the draft.

C

All we can deliver some level of security and we simply put and say that privacy, nothing is perfect, but it's way better than what we are using right now and I see. Now, that's the last one, okay question: any questions.

A

So maybe we have asked the the security Directorate to take a look to give us another point of view. Okay, so hopefully they will provide some feedback, I guess they were swamped by this. He knows this meeting I mean so not yet, but hopefully we'll get some song external point of view and take a look at this answers. I don't know if everything is capturing. The in the eye wants to you: okay, perfect, okay, so thank you and thank you for asking Thanks.

A

Okay, next is mark in the room: No, okay, so then I guess we can go to to Tom.

E

Hi I'm Tom Herbert I'm gonna give an update on generic UDP encapsulation.

E

So there's two drafts that we'll talk about so one is base. Goo draft, that's in version 5. It is in working group. Last call not a lot of comments in the last call, but we did have quite a few pretty in-depth reviews. Previously, the only major change to the latest revision goo version became goo variant, so joke touch had a concern. That version implies kind of precedents for obsolescence of previous versions.

E

So variant gives us a little more flexibility, so it could be kind of like a canonical version or in the case version zero version versus version, 1 of goo they're, really different kind of variants. Version 1 happened to be a very compressed form.

E

So, just a couple of possible future updates, so one of the things we may do the C type field right now. If the control bit is said in one of the goo header, this indicates a control type. It occurred to me that you will encapsulate any IP protocol, but there are things that we may want to encapsulate in the future, for instance another UDP based protocol. So, for instance, we could have Lisp over go a beer over go the reason to do that is goo kind of provides some general and capsulation features and capabilities.

E

It's not really about specific use cases. So, for instance, if you wanted to add fragmentation of go to something like list, we could do that. So it's a possible thing. We could add another thing that could be pondered as I'm, adding a private data. So goo has this concept of private data within the header, but we never really specified a format for that conceivably, we could add a flag field that says what the format is, so it could be. Some sort of tlvs or additional types of format could be an embedded alternative protocol.

E

So one possibility the other thing is goo is udp-based. However, it's not really inherent that it has to be in UDP conceivably. We can make it an IP protocol in itself or Ethernet code, point, probably a little easier, since it has a larger space. The advantage of that is would be kind of a common encapsulation protocol, similar to how GRE operates in those three modes, but in case of goo might be a little more extendable in the future.

E

So the other draft is go extensions. This is in version 3 again in working group. Last call not many comments. It has received some some review. The current state is, there are eight extensions defined and, like I mentioned they're really about encapsulation and an 11 of 16 flag bits have been allocated so the obvious problem here is we only have 16 flag bits. So what happens when we run out of flag bits, because we had extensions?

E

The answer to that which is actually on the next slide. The antenna is at the last bit in the flag field will indicate a new set of flags as in another field, this was actually an earlier version of good. We removed it because the point was that our definition of defining Flags we wanted to find them contiguously. So in the future, once we hit the limitation, that's last bit is intended to give us another set of flag fields, and then that gives us 32 more.

E

The estimate that I think is probably pretty accurate about one flag bit per year allocated so 32 plus 5. So hopefully we have about 30 years of lifetime before we have to go through that. That again, like I, said one of the reasons why we don't think, there's going to be a lot of extent.

E

Few extensions really are just about encapsulation, not specific use cases. So for specific, specific use cases we would want to put those in a different place in the packet either the private fields or inside, like I said we could have an encapsulation of another type protocol and I forgot to mention. So we didn't make one major edition in the latest version of the go extensions. That's an alternate checksum. This is something similar to UDP options. In this case we have a crc32 CRC, 16 and CRC ccitt.

E

The reason why there's two CRC 16 it was really difficult to find, which one kind of has is more important, they're, both equally used in different contexts, so UDP options, for instance, you is that the latter linux turns out. It has the first one implemented so they're both there. The good news is that it's a configuration thing, so you can only use this if both sides kind of agreed on it. Anyway, there was one important point and I think this is actually coming out in UDP options.

E

Also, if we make a CRC or security field or anything like that optional and it covers the header, they do not protect the actual option. So, for instance, if this were a TLV and we had a TLV type, it said this is a CRC. If that TLV type became corrupted, it would turn into something else. The receiver might not see the CRC, so the value of having the CRC goes down. If this is one reason why we like to have like TCP check sum, UDP checksum are inherent in the packet.

E

So that's one thing: we make a note of that. The answer here is it's a configuration option. If the receiver expects security or expects the CRC and doesn't see it, then they should drop the packet and make a note of it.

E

The GU flag field extension like I, mentioned it's intended to be the last bit of the flags.

E

So the idea is the I guess that the 31st bit would be the e bit and that will point to a new flag field, so that 32-bits it looks like just like any other Flags field, but when we're processing the flags after the initial flags, our process will hop down to that and then continue processing, flags and then fields for those flags follow all of that's fairly straightforward thinking about new possible new extensions, I think the OEM measurement bits. So there are two of them defined for 8321.

E

That may be very reasonable to put into goo flag fields. Also, a group based policy may be reasonable and, as I mentioned, if we won't want it to format private data, the format type may be in a in a field, and that would indicate what the type is of the private data.

E

So that's all I had any questions.

F

Corie Corie first.

G

F

Curious about why you think you need three different CRC formats. It's like how long is your data? Is that not the only thing that would drive that the choices CIC into our ability seems more key to having lots of options here.

E

It's um it's a two bit field, so we have four. We have three combinations, so crc32 kind of makes sense, because that's either at CRC. But the argument there is well that's kind of expensive. So what about a CRC 16? So, like I said it was? It was kind of a coin toss I did not have a strong opinion, but I couldn't find any good precedence either with an IETF or with in general networking community about which is preferred I. Don't think it particularly cost us anything except a couple of flag bits. Yeah.

F

We also cost of and what less interoperability here I mean. This is like creating options just for the sake of it, I mean, and we chose a CIC, 32 I think in a CTP and look at the SCTP story and you'll find why and why. We think. That's actually, okay, there.

H

Are they're not a normal.

F

Crc the earth you can choose either CRC and 30 to depend on what you want. What you think is better I mean it. They don't have that much different properties. There is a document actually discusses the difference between the two computationally. It's not that much more expensive than their CRC 16 I. Don't.

E

Have a strong opinion honestly: if we can, we can chuck the CRC 16. If that's fine I would point out one thing that we did do all the CRC's, the checksum that we have and the security they all have the length field. So it's kind of like a UDP light thing, so we cover so it is optional. Data included, so I kind of like that aspect of it like I, said I, don't have a strong opinion. It's that's good feedback.

H

They've heard like verbal ink CRC hurts you oughta, hey you you're, trying to verify integrity. You shouldn't make it more complex. Let me give if you want to use more than one format. Let me give you a second option and explain why it's cheaper and why it helps the second option is to grab the grab. What's commonly known as the I, scuzzy, CRC or crc32, see. There's two good reasons to do this. One is the polynomial is different.

H

So if you're running over Ethernet, you get added cheque as opposed to running the same polynomial over roughly the same data, and the second is that Acer processors are a certain well-known processor vendor and possibly others have instructions that directly compute this sucker. So it's cheap, so.

E

The argument was, we have two men and I are suggesting another I'm.

H

Suggesting and not dropped I'm suggesting a two-stage approach: one toss the 16s. Now you down to one. If somebody would like to go, explain why crc32 is too expensive in software, you could add crc32 C and require everybody to do both because that one's cheaper and software well.

E

I mean I would point out that crc32 is already implemented in the Selfridge and generally right so for implementation, wise that is you'd like to stop and step one I'm, not gonna I'm, not going to complain, okay, point taken.

E

If there's a preference, then you know I'm more than willing to go with one I think it's a it's a good concept to have it in general. So.

F

Gory, fascist is TS, VW culture. Why don't you just ask auntie s vwg, because if you want to choose a CRC, then I think you'll get some feedback, wait which one Oh ask about your chosen CRC. Is it suitable on TS, vwg, okay, yeah on the transport area, will give you some fever a lot and different other prom skills? Okay, that's a good point.

E

Thank you. Thank you. Thank.

A

You very much don't go too far away: Tom Tom, Tom, Tom.

A

You have two more.

E

Okay, hi I'm, Tom Herbert.

E

I'll get an update on I Elena.

E

So we have the ILA buff on Thursday. This is a non working group forming boss. The intent is to highlight problem statement use cases. This is not intended to be an in-depth discussion in of solutions, and we've had quite a bit of discussion on the mailing list. So since last IETF there was an ila mailing lists created. A lot of the discussion gets down into security, scalability mapping systems, denial service threat and, most recently, there's discussion on an Iowa, Lisp kind of control plane. So the idea is to use list control plane for ila.

E

That's a pretty promising. There's also been some discussions on DMM and the five gang an IP list. Those discussions tend to be more specific to the mobile use case. It would point out that ila is kind of trying to be a generic, but mobile is one of the use cases, data center, virtualization network virtualization or some of the others we're also looking at the 3gpp steady item that they're looking at perhaps ila could be part of that solution.

E

So that I'm getting a little bit of update on the data plane discussions, so ila is explicitly not encapsulation, and that means there are no bits at it to do transformations. So we have no extensibility no way to encode everything. In that sense, it's kind of the the opposite of generic UDP encapsulation.

E

What that means is everything needs to fit into basically the destination address, and the idea idea viola is that we transform addresses in order to get them to their destination and before the receiver actually gets the packet we always transform back to the original address. So it's kind of like a paired address modification so because everything fits needs to fit into this small space. We have relaxed a little bit on the canonical 64 64 split so, for instance, in il NP.

E

There was this idea of a 64 bit locator 64 bit identifier, that's kind of some simple architectural e, but when you start thinking about different encodings and different things, you might want to do it's a little less flexible, so we're relaxing on that, and that gives us the ability to do some interesting techniques. One of the techniques is locator indexing which you would use if we wanted to encode / 64 assignments into il a another. One is chaining, so, instead of just doing one il a transfer transformation, we may do multiple ones on the path.

E

This is kind of a poor man's segment, routing where we can adjust the destination address, have the packet visit certain destinations based on hop-by-hop routing and at the very end again the packet has to be transformed back into the original packet, so that the receiver has no idea that this happened. This does represent a bit of a trade off. So in order to keep the data plane simple, that implies a little more complexity in the control plane. So that's kind of the the ILA trade-off.

E

The control plane pretty quickly gets to identify your locator split, scalability type of issues, and this has a lot to do with mapping systems an identifier, locator split. We do think there's gonna be mapping systems, so imagine a large network. Everything is somehow virtualized or mobile. We need a way to find out where, where identifiers are identifiers are basically the logical nodes. So for that we need a mapping system. This is pretty I, guess pretty accepted in the identifier locator space.

E

So the question right now is how to do this mapping system it's little little independent, violate I think there are some things that ila kind of implies in a mapping system, but fundamentally the mapping system does have kind of four pillars: the scalability security privacy and das ability aspects. So I think a lot of that will come out in the ILA Boff, maybe a little bit more detail but again the solution.

E

It's about the problem of statement right now and the use case is a little bit less on the solution. So again, that's Thursday.

E

18:10 and discount thank.

A

You very much so that's a teaser for the buff that will take place and in the interest of time maybe we can move to the to the next presentation and leave discussion for that. Buff. That's! Okay!.

A

E

Okay, one more so this is like kind of an out offshoot of some of those things. We've been looking at ila, and this is particularly looking at the privacy and prefix assignment so I. We have a few caveats up front just to make it clear, so this is only considering privacy at the networking layer, specifically in addressing privacy itself on the internet, has to be considered every layer. We know that this is considering one aspect of that.

E

This is also only considering risk from third parties interpreting or inferring information from IP addresses, so that specifically means we're not considering network providers that have say for mapping of IP address device, it's up to them to to secure that data and I'm, not sure we can do much technically to solve that problem and equivalent equivalently. This doesn't address law enforcement or authorities who can compel say network providers to release that information. So, like I said those are caveats up front. We understand that and privacy is a multi-pronged problem, as we know.

E

So what about prefix assignment so / 64, addressing it to host, is actually becoming quite common, so slack, for instance, is doing that and it's actually pretty common in mobile networks. You E's get full / 64. This actually recommended no RC 33 14, so that gives us some properties and since the prefix is being assigned to the device, that means there's kind of a 1:1 relationship between a prefix and a device. So given two addresses that share the same prefix, even if the ID is different, the interface identifier.

E

In this scenario, they actually would refer to the same device and that becomes a little more problematic in the case that we're assigning to say a Ewing in a mobile network like a smartphone, then there, because of much higher probability, that that devices actually corresponds to a specific user. So now we have a one to one relationship, potentially between the prefix and then actual user and another issue. Prefix may contain fine grain hierarchy for routing and that's going to have to do become a problem if that reveals location of the device and hence the user.

E

So the privacy issue is kind of implied from that the prefix becomes an identifier for the device. The addresses are used in the public internet. So if a third party knows that a site is assigning prefixes, then if it sees two addresses, it can infer that they are the same device if they have the same prefix. So this exposes the risks of revealing user identity and communicate, Shen's and location location of users.

E

If location information is actually encoded in the prefix, so this specific issue was actually raised in RFC forty nine forty one, seventy seven to twenty one, maybe some others and periodically changing the interface identifier in forty nine forty one actually is no help, because the problem potential problem is in the prefix, not in the interface identifier.

E

So we could extrapolate from our C 49-41 to just change the prefix periodically and conceptually that's possible. We do know that changing addresses. If there's only one and you change it periodically will probably kill all the existing flows and they have to be restarted. So assuming we solve that problem, then the real question becomes. What is the correct frequency to change?

E

Addresses in order to ensure privacy and it's a tricky question I did pose this on a couple of lists and there really isn't a very good answer, because someone could say a day or a week or an hour and there's no way to quantify what kind of privacy you get out of that. So the conclusion that I posted it was anything less than a different address per connection or per flow theoretically could have a privacy exploit and actually gave an example in the in the draft.

E

You can read it about a proposed exploit that I could take advantage of of that, so any reuse of a prefix or address could be exploited to figure out identity.

E

So from that, we can consider what what are we really shooting for and their privacy and addresses so I gave an example of a couple criteria, and this is based on if I have two addresses and no other information.

E

What can I infer from these two addresses, and it is obvious that you can infer they're from the same provider same organization, so they will share, say a common network prefix, that's kind of basic and maybe also that they belong to a very broad geographic grouping, so would be expected that a large organization would probably want to have some Geographic or regional hierarchy. But beyond that, the idea is. The viewer of these addresses should not be able to do this any other information.

E

Specifically, they can't tell that the notes that are associated with these addresses are not the same node or in the same rack or at the same location or have any other proximity, so that's I, think kind of a I, don't think it's strict I think that's just some criteria for privacy. Addressing that will propose now. I would point out that network address translation net can actually meet these criteria.

E

If there's a large enough address, pull because, basically, what NAT does? Is it obvious gates? The underlying addresses of the network and what you get on the wire on the Internet is the address of the net device and some port number, and the port number refers to the specific instance, but external users. They don't see that so it turns out net, actually meets these strong criteria as pointing on the document.

E

I do think this is one reason why some some law enforcement agencies are a little paranoid of that because it does such a in sense such a good job, job of hiding identity.

E

So the document does present a possible solution and, like I, said this kind of wasn't sub problem of NAT or not at NAPA to vial a so with identifier, locator split. The idea is that we can use identifier locator split, so the identifier becomes independent of location and we can assign multiple identifiers x', hence untrackable addresses to host the address is still share a common prefix, but if this is done with enough randomization, they would share nothing else. So to address is assigned to a host.

E

The same host would have nothing in common except that prefix, so that would meet the strong criterion and then add a privacy and a dressing so for maximum privacy. Then, because of the the result that we need to use an address per flow means. We have a lot of addresses, potentially that's, obviously a scaling problem.

E

So looking at some of the potential mitigations there, one thing is not everyone necessarily needs his privacy, so in some sense this could be a service if somebody really needed that level of privacy in one of the one time yes address. This could be a way to accomplish that. Maybe there are other communications or aren't necessarily that private. They don't need that. Obviously, that's not a great solution, because now we're forcing the user to make a decision and we'd rather give them perfect privacy all the time.

E

So another way to look at this problem is what we're actually trying to do. We actually want to aggregate addresses as being as belonging to the same host, so we can get the addresses to the right host and that's the problem that the mapping system has. So there is aggregation here, so the question we're pondering is: can we do a sort of hidden aggregation where the network can assign a host a block of addresses and to the outside world?

E

This block looks completely randomized, however, the network, either through some sort of public key encryption or some type of hash, is able to deduce that these addresses actually aggregate to the same node in this case. So this is the concept of hitting aggregation, so the first level would be local network has a way to create these addresses, assign them to the hosts, and only the local network would understand this.

E

If that problem is solved, then the question becomes: how do I do a bulk aggregation because we still don't want to have to give hosts individual address? Theoretically, they could require thousands or millions of these. Is there a way to give a host a way to create a block of addresses itself and whatever needs a new address? It can create an address, say we give it blocks of 64,000 IP addresses and it can use them as needed and when it runs out, it can ask for new ones.

E

So those are kind of some of the things were we're looking at and again, this is kind of along the lines of how identifiers locator may solve they solved that issue. Any questions.

G

Hi Tim Chan I've got more points than I should probably make here so to say a couple. Take the rest of this. So.

I

I think the first one.

G

Is I think this is useful having prefix privacy I? Think if you compare it to the privacy for hosts as it stands, you're probably going to want to be able to have persistent, prefixes and private prefixes. So you need to be able to somehow delegate a prefix, that's Marxist for use as a kind of a privacy review. First I guess so.

E

So you we would, we would do a block some sort of block delegation where it's not a prefix right, it's actually a block for for privacy. That way is that what you're referring to.

G

Well, if I was say, for example, in mine, something has been allocated to my home network, for example- then maybe having a rotating prefix out of the ISPs prefix, that I can use to initiate new connections for movie good thing, while I've still got a persistent prefix, that I can have my services on without running, don't DNS or other things to update and essentially have to renumber my network. Every time you continue and privacy prefix I think would be important. Well,.

E

I mean so I'm, not sure it's it's so much for numbering right, it's more temporary address assignment I think is the best way to phrase it, so the addresses could be requested on demand in some sense. So obviously, if you want a persistent prefix because you're a server, then that that might be a different story, yeah.

G

But otherwise it.

E

G

Were potentially going to assign me addresses that might be shared between multiple customers or something, and that starts getting quite I, had shares lots of problems that we have with cgn and so on today.

G

Doesn't it I think, as a user I, think a lot of users are aware of privacy issues and that's why they use things VPNs like hidemyass or whatever other ones they fancy using tor whatever so I think this awareness I think what we're trying to do here is to provide some more subtle privacy that users may not ask for, but I would like them on my own network to not affect things I'm running as services in my network, I share.

J

G

Problem with doing this big block and giving a host Zeeland addresses that it can use, you are into all sorts, the other things that have been discussed for things like nd cache, exhaustion and so on. There's all sorts of things that if you try and use an address per application, they're going to hit you in in otherwise I.

E

Mean there's a lot of legacy towards this right. I think.

G

It's it's a really good topic. Well, I! Think, there's because I think just throwing a ila. It is an answer, but I think there's more pragmatic things that need to be considered. First, okay,.

A

I'm cutting the line now here we had someone in mute ago, I, don't know if they'd still want to have his place, but I think Lauren. Oh.

K

I think I think stating the goals like you stated them is: is sudha misleading. At the beginning, you said it is entirely out of scope to think about anything that the ice P can do to attack privacy or anything that sends anyone that has the power to compel the ISP can do.

K

You declared that to be out of scope on slide one, but it doesn't mean that just by making it out of scope, you can there is a privacy trade-off there, for example, a scheme like the one where you assign let's say that the ISP assigns you want ipv6 address for every different connection right.

K

Yes, you can declare ISP sort of privacy to be out of scope, but the fact of the matter is: if we build the scheme, then the ISP has to maintain a record of everything that you did, whereas in the case where it has to keep every base, essentially every tea, every TCP connection right, whereas in the ski, where the SP just assigned to your prefix that rotates they don't have to keep all that information about you. So, yes, you could declare it out of scope but you're, basically moving a slider around where you know.

K

Different parties have different views of how much activity of what activity you conduct online and the solutions here are basically all on the other side of that slider, because one side of its out of scope but I think that's not a full solution to the problem. Well,.

E

So let me ask a question: so NAT exists today right and that is not prefix assignment in the sense. So externally, what you get with NAT is something that apparently is randomized. So as far as I know, most ISPs are required to keep all NAT mappings correct. You know, I, don't know that. Well,.

K

E

This the data is the same, so nat effectively gives you a different source address per connection as far as the outside world is concerned. So if they want to do an AB.

G

You know the down mappings.

E

At that time, I think that's that's the argument that law enforcement is making, but it's not clear to me why that or that argument is because it seemed like the nat logs are sufficient, in which case if the net logs are sufficient, then the logs of address assignment in this case should also be sufficient. At least that's my understanding of the problem so.

K

It's not clear, even I mean it sort of becomes free murky, because it's not even clear whether the the party on the other end, like the server, actually keeps source ports right so well.

E

Right but but the server is a different thing, because the server can be anywhere on the.

I

K

E

Don't have the source port there's nothing that can be tracked right. Well, no, if I know, if I know what I'm looking at. If I know, then that translation, then I can reverse engineer. Who was sending that if.

K

You're behind in that, if you have the logs yeah, nothing that keeps lux, but so like I said, I think it was not necessarily a specific suggestion about these points. I think I think basically I think basically declaring that attack vector to be out of scope is an error, because it means that we can like, because it means that any solution that entirely gives the ISP with access TSP all this information, basically we're completely disregarding that downside, because the way we set the goals right but.

E

They already, they already have all that information. You know it's not true. Well the people they do. They have that because they have the prefix to device information. They hope they have.

G

E

Don't have to track every connection if you don't have to track every connection here either. What we said is you can you can assign addresses to device it? They can use them. However, they want it's not necessarily for connection all right.

K

That's right not.

E

Necessarily but like I said.

K

The one scheme that you proposed was different address for connection that requires 100% participation for the person rit's routing the packets to that address. Yes,.

E

K

Is that my point is on that last slide, where you propose several different arguments? The only difference between those is the amount of information the ISP gets, which on slide one. You declare to be out of scope, so I think that's kind of disingenuous. That's.

E

Right, but look at this way if I saw assign an address now and they use it only for one connection, then they only use it for one connection, the ISP doesn't know what connection they use that for it's, not it's not like NAT. Now you actually have more information, because that is about the actual connection. This is I mean it I know it's a subtle point. This is just the address assignment. That's what needs to is what needs to be tracked when the request doesn't say: I want to create a connection to this destination.

E

Give me an address, but you the.

K

Requester says give.

E

Me an address, but you would like I'm said, like I'm saying it's I'm.

K

Talking about the goals, not the proposals, okay,.

E

So you say their goal, but we have to track. Do connection tracking.

K

Is that the goal is that we have to provide privacy, and we can't just just hand wave our hands and say whatever the I species is out of scope, because one scheme that satisfies your goals entirely is that the ice P logs every five couple? No.

E

K

L

Not part of this well.

E

That satisfies that too right. So what we're trying not to do now? Okay,.

A

We can take this one to the to a list. Maybe we go to the next one and the line, then we have me to go and the last person hi.

I

I'm kyla rose. This might be a dumb comment, but if we're giving do to the 16 IP addresses to every host, could that actually lead to ISPs with millions of posts run out of IPs I know.

G

I

His big, but do the sixteen pretty big two as.

E

Opposed to two to the 64 that they're getting today, oh so are we talking about handing out like slash 96 or something won't block blocks of to box of 2 to the 16th 128-bit addresses sorry, ok,.

I

Not Creek, sorry that wasn't done.

E

Before sensitive Thanks so.

A

Next, we go to me to go Dave hi.

M

There it's Dave O'reilly here, I'll, be speaking later, but I just wanted to jump in with a couple of points about and I guess you could call it. The law enforcement perspective on this I'm, not a law enforcement officer, but I do work with them.

M

A lot and I understand their perspective and the perspective on a situation like this would be and that if there has been some criminal activity and that activity is associated with a particular IP address, what the law enforcement officer is going to be interested in is who was controlling that IP address at a particular time at the moment, almost everywhere in the world. I can't, obviously I can't speak for the entire planet, but everywhere that I've ever worked.

M

It has been a requirement, a regulatory requirement on ISPs to be able to identify their customers, and this touches on what I'll be talking about later. But it seems to me that whether a whole block of 64 IP addresses is allocated to a particular person to a particular host or whether the IP address has to keep connection logs. There are two solutions to the ultimate problem, which is that ISPs will be required under regulation to be able to identify their subscribers now. So that was my first point.

M

Whatever way it pounds.I, that's gonna be the case. The other point that I wanted to make was I am of the opinion. I hope this is not too controversial comments that, for a plethora of reasons, connection logging is a terrible idea, and the main reason, I think is the risk of loss of that data is, is huge to the privacy of the individuals concerned.

M

So ISPs have data breaches, just like everybody else, and if all my connection logs got out, they can see everything that I was browsing at every moment and so on and so forth, which is why and I I'm resistant to that idea. So as long as there is some alternative mechanism by which individuals like ISPs can meet the regulatory obligations to be able to identify to subscribers, that's really the point that I wanted to make.

E

Okay, those are good points but again I point out that the this solution actually is not connection logging. It's more budget address registration, so it's effectively what we have today with a prefix to device, but it might be a greater scale, so it'd be address to device, but it wouldn't be going as far as NAT, which is clearly connection logging, so that that wouldn't occur and I'm, assuming that law enforcement has to have NAT logs today already.

E

So it's kind of like that that component, at least in terms of scalability, should already exist as far as I can tell so.

L

That doesn't require a connection logging. You can't do that, but you don't have to port block allocation, so.

E

You're just you're just your.

L

Tourist boards horse address. Okay, you don't have to log all the connections just because you're running that, okay, great so that's less data you can. But it's really like the logging requirements. Just thanks.

N

So, let's person on the mic, please I nicked, OD, UC, Berkeley and I'm coming a little bit.

K

New to this area, I work mostly at the web level, but and I'm particularly curious about you're. Talking about the timing of rotation of rotating identifier, z' and I feel like there's a particular concern about like that. If we have too many AI identifiers that are getting rotated at different times, we might lose the privacy benefit of rotating identifiers.

K

So I'm curious about like whether whether the Klein has controller whether the clients like or having some guidance so that we're rotating all they identify up and diet.

G

K

At the same time, otherwise all the end servers can just line them up and actually sort of figure out. Every change identified. Okay,.

E

So real quick, so one I think the client should have the control plane gets addresses from the provider. Client should use them as it sees fit. So I think that's pretty clear. Two. Please look at the draft because I give the example a potential exploit that could defeat any frequency except once per connect or once one per flow.

E

That example hasn't been refuted, so it may be, may be accurate. So if you have any ideas on whether it could actually happen, I I've received this one thing, I think is: privacy is probably such a big problem that maybe HAP. Maybe the attackers haven't gone down to this level yet, but I do think it's gonna be a problem at some point doing it. Oh thank.

A

You very much yep fine thanks a lot Ron.

J

Helooo ron Bonica, the chairs, have asked me to shorten the presentation up a little bit so I'm gonna skip over a couple slides this. This craft used to be called ipv6 fragmentation considered fragile and, as we were, writing it realized most of our criticisms applied to ipv4 as much as ipv6. So we renamed it it's now. Ip fragmentation considered fragile.

J

What are we doing in this draft? Well, we've known for a long time. Fragmentation reduces the reliability of internet communication in this document. We're going to talk about what fragmentation is a little bit and that we do it with document we'll skip over it in the presentation we'll talk about how fragmentation fragmentation reduces reliability and we'll put out some recommendations for protocol developers and network operators now keep in mind we're not talking about deprecating fragmentation that just can't be done.

J

What we're talking about is pointing out how it makes it, how fragmentation makes communications fragile and strongly recommending that protocol developers wean themselves off a dependency on fragmentation.

J

So there's some terminology: you need to know to play the game. I'll assume that you all everybody in this room knows what an MTU the minimum link, MTU and PMT you is I'll. Also assume everybody in the room knows how IP fragmentation works. I'm just gonna point out two things: one is a small difference between how ipv4 fragmentation works and ipv6 fragmentation works. An ipv4. You have this thing called the DF bit. If it is set, a packet cannot be further fragmented downstream.

J

If it is clear, a packet can be set for the fragment at downstream an ipv6. There is no DF bit a packet can never be further fragment at downstream. It can only be fragmented at its source.

J

The next thing that fragmentation has in common between ipv4 and ipv6 is when you fragment a packet, you divide it into pieces. The upper layer, header always appears in the first fragment. It never appears in subsequent fragments this. This observation about where the upper layer header is, is what brings half of the fragility into the argument now.

J

In an environment where only the source can fragment a packet, the source of a packet needs to do one of three things: either restrict itself to sending packets that it knows will never be fragmented. That's for ipv6, never sending a packet back bigger than 12 80 for ipv4 and never sending a packet bigger than some arbitrarily small size.

J

So that's one thing: it can do another thing it can do is PMT UD path, MTU discovery, so it discovers the MTU of the path ahead of it, and the third thing is packetization layer, P, MTU discovery and we'll talk about each of those for a second PM tud. The source node makes an initial estimate of the PMT you to a destination. That estimate may be too large. It then starts sending packets to the destination. If the packet is larger than the actual PM tud of the actual PM to you, it will not be fordable.

J

It'll get dropped and a downstream writer router will send an ICMP packet too big message to the source, the source. Having received that will update its estimate of the PM to you. Now this strategy, PMT UD, absolutely requires the network to be able to deliver ICMP PT P messages, if it can't do that, it's black hole time.

J

The next alternative is PL PMT UD. Here we push the problem up to the packetization layer. The packetization layer will say: TCP in-band sends packets of different sizes to its TCP peer. What it's doing is probing to find the PMT you. It relies on two things. Primarily, it relies on acknowledgments of its probes at the TCP layer. It can also rely on ICMP feedback, but then again it's perfect in PLM, PLP, MTU D. The endpoint is perfectly able to ignore the ICMP messages. It doesn't need them at all.

J

Plp MTU D is defined for TCP in RFC 48:21, it's being defined for some other protocols and draft Fairhurst going on in the TSV working group. Sadly, it's not defined for UDP and it can't be because PLP MTU D kind of assumes a long live session. Well, a session, not a one in dumb packet, the other thing about PLP, MTU D. It doesn't rely on ICMP ptb messages at all. If they're all dropped, PLP MTU D still works just fine, so we've talked about the status quo. Now it's time to leap in and talk about.

J

Why is it that fragmentation makes communications unstable or fragile? Well, one problem: well, these problems all link back to the problem that the frag only the first fragment has the transport layer header in it. What are the impacts of that? Well, let's say for a minute: you're, a load balancer and you're a load balancer that load balance is on TCP ports if the TCP port is only in the first fragment you're bound to suboptimal load.

J

Balancing next issue is firewalls, let's say you're a firewall and you have a rule that says: block all packets based on the TCP destination port. Well, you can configure that firewall. Two ways one way is to accept all subsequent fragments. That's a little bit too liberal. Another way is to drop all subsequent fragments that one's a little too restrictive, there's no healthy middle ground. Other middleboxes can have the same kinds of problem because they need access to the TCP header or the transport layer header, for instance.

J

Let's say: you're a middle box, that's remarking the dscp based on the TCP port number, it's fine for the first fragment. What do you do for fragments to through? In.

J

There are some other well-known problems with fragmentation that don't have to do with the TC, with the transport layer header not being in subsequent fragments. There are bunches of security vulnerabilities that have been documented over the over the years: overlapping fragment attacks like the ROS attack, resource exhaustion, attacks and many more. We won't go into them now, they're in the draft, but there's an interesting problem: around TCP loss around ICMP loss, PM, tu, PM, tu d- fails when you are losing ICMP packets, ICMP packets can be lost for bunches of reasons.

J

One is because network operators are filtering them, they shouldn't there's an RFC. That said that says they shouldn't another is, you know just play: don't packet loss or rate limiting those things happen, but they're not insurmountable problems. There is at least one insurmountable problem and it has to do with any caste I'll give you this example from Jeff Houston's work.

J

Let's say for a minute that a DNS client sends a DNS request to an anycast address. It's a common thing to have happen that it arrives at a DNS server. The DNS server sends back a very large response. It's running DNS X, so the response is going to be big, that people are laughing.

J

That response gets to a point where it cannot be forwarded because of an MTU problem, so the node that could not forward the DNS response sends an ICMP message back to the of the packet. The source of the packet is in anycast address and it goes to some DNS server that has that anycast address, unfortunately, not the one that sent the packet that's problematic, it's black hole time.

J

Another problem is network operators tend to filter, fragmented packets. There are two studies, one by Fernando gods and other by Jeff Houston that that demonstrate this. We don't quite quite know why they do it. We just know that they do so.

A

J

We have some solutions at the transport layer. We've talked about them already, we'll go quickly. Let's get to the recommendations, so I can yield the floor. We have some recommendations to application developers that they should not develop applications that rely on a PI, P fragmentation and, what's more, if there were any that accrue shal to the Internet infrastructure, they should be rethinking those applications, so they will rely less on IP fragmentation.

J

The next is for network operators. They must not filter ICMP, Petey B's, that's already in another RFC, so it's not crucial, but the big one is for DNS and especially when DNS is using DNS SEC, they should be finding ways to not rely on IP fragmentation and anyhow. They ask next steps is to adopt this as a working group document. Okay,.

A

So can I have a raise of hands. How many people have read this draft okay to be starting. So, as you know, we're running out of time, so maybe I'll take one question and then we keep moving we'll take it to the list, I think before adopting as working group, but that's a good show of interest in it. David.

H

Black I mean--the, another transfer area and I'm here to help you Ron I'm, going to say a dirty word tunnels. Please make sure that what you do here is lined up with the int area. Tunnels draft we're fragmentation is used to solve some nasty problems with tunnels it. We really ought to have a consistent story across the two of them. Thank you. Okay. Thanks a lot.

A

O

Hi so I'm gonna give you a quick update on our work on Sox version. Six I'll start by giving you a brief overview of where we're at so we've trimmed down the are cheating the overhead in terms of our GT down to 0. If 0 RTT authentication is used for in order to protect against malicious l parties, we've taken a step back and rather than having sox, provide an encryption. We've decided to run, run it over TLS and then handle whatever issues. Tls has notably TLS TLS.

O

Only data is prone to replay attacks and we have a mechanism that mitigates such attacks. Now that we're running we're also running stocks over TLS plaintext, password authentication is actually viable. And finally, we have added a new we've leveraged stocks options to add a new set saw copped and get saw cup-like mechanism and we've used it to implement some stuff related to MPT CP more on that later so stocks version 5 starts by negotiating the method of authentication.

O

Then it does within the authentication and the client requests that the server the proxy establish some connection to the server and then finally, application data. Can pass through Sox version 6, in contrast, sends as much data out front as possible, so we cram in the authentication method, negotiation, negotiation and the address of the server and also some application data.

O

We cram it all into the first message sent over to the proxy and, of course, if 0tt authentication is used, the server sends off and can send an operation apply as soon as it touches the connection to the through the remote server.

O

Speaking of 0rt authentication. This is this is how how a password authentication is done in a zero RTD manner, so draft so I see 19:29 describes how password authentication is performed for Sox.

O

Basically, we can just take the the the initial message sent by the client, which contains the username and password and place it inside a Sox authentication data option. Now, of course, there's a small caveat to that. If the username or and/or password I are exceptionally long, it simply won't fit in that option and you have to do it the old-fashioned way, which takes up one extra RTT. However, this is unlikely.

O

Next up, we've got socket options. There's been some discussion on the mailing lists, notably David. He brought up the point that sockets are actually an OS construct and connections are necessarily TCP. Connections are necessarily done using sockets, so we're going to rename these options in the next version of the draft.

O

Clients can use these options can include these options in the in the Sox requests, in order to request certain behavior from the proxy and proxies can include them in operation. Reply to advertise their behaviors.

O

The fields I want to draw your attention to are like level code and data, so the leg baker basically indicates what what leg behavior reply refers to. It can either be a client proxy like the proxy server leg or both legs, then the next three, the next three fields were actually inspired by sets or captain gets a cop. We've got left operation code and data for possible levels are a genetic socket level. Then we've got levels for eye for the track left three protocols, namely ipv4 and ipv6, and two more levels for TCP and UDP.

O

We've used the socket options to handle GFO, so that previously was a field in the request which indicated whether or not the proxy should attempt to use the fo. Now we've removed that field and when a client wants the proxy to use the fo, it simply includes this option as part of its request. The absence of such an option means that the server must not use must not attempt to use the fo.

O

Next up, we've also used these options to implement a use case called proxy bypass. So let's say that a mobile phone once has both a Wi-Fi and the 4G interface, and it wants to take advantage of both interfaces. Now most, as you probably know, MPT CP deployment is lagging behind on the server side. So, if you, if, let's say a mobile phone, wants to take advantage of both of its interfaces, it probably has to go through a proxy.

O

Now some servers, my template, might start start deploying MP TCP now, in case in case on a server, does support MP TCP the proxy can place an MP TCP option in its operation. Reply signaling to the client that the upstream server does indeed support MP TCP, then the client can forego the use of the proxy and talk to the server directly in further connection attempts.

O

And, finally, we can use these options which to change the MP TCP scheduler used by the proxy, so clients can can place such a request to indicate what's what's what packet scheduler they want. We currently support the packets Jewellers available in the the lyrics NP tcp implementation and proxies can include them as part of operation replies to tell clients what schedulers they are using.

O

We found one possible use case for this option, namely low latency services. So if a client wishes to have low latency, it can tell the server it can get tell the proxy to duplicate data across all MP TCP sub flows such that the delay is always minimal and with that I'll be happy to take questions thanks.

A

Can I have a raise of hands who has read the the latest version of this draft? Ok, who has read any version of this draft? Ok, so we definitely encourage people to comment on this latest version. If you, if you can, please take a look and send comments to blood. Thank you very much. We're ranking short of time, so we're gonna move being be moving on now, Thanks. So.

A

Next is Dave remote.

M

I

M

Hi, okay, so hello, everybody, and thanks for the opportunity to present this I'll, be as close to five minutes as I. Possibly can so now. Next slide, please yep, so I'd like to begin by describing what the currently published best practice is, which is RFC 6002 on logging recommendations for internet facing servers. Okay. So what that document recommends is that as well as logging, incoming IP addresses servers, also log incoming source port numbers and time stamps and transport protocol as well?

M

But why and the answer is because of large scale address sharing technologies such as carrier grade math in the presence of these technologies.

M

This additional information is required in order to attribute the activity of an IP address, two to two at the very least, to an ISP, but ideally down to an individual from a crime investigation. Point of view, so in the presence of large scale, Nats IP address is not enough. You need this extra information as well. That's not to say that if you did have all this information, you would successfully be able to identify an individual from this.

M

It's just the information that is required to address the problem that is presented by carrier grade nat and and related technologies like ipv4 to ipv6 mapping technologies very similar problem next slide. Please can.

M

So I did a little bit of research and what I found was that, while stars recommendation stats, that's fine, they are what they are, but they're not enough, and here are some of the issues that I that I identified. So somebody who was considering implementing those recommendations might find that their server software might not support logging of source ports and that would prevent them from being able to achieve the recommendations.

M

Another thing that has that I have seen is that certain server software, the only way that you can enable logging of source port is by enabling a ridiculously verbose level of logging, like debug logging, or something like that, which you're never going to do on a production server. So whilst it may be, it may be technically possible. It's infeasible to implement source port logging now practically no server. Software enables it by default, and indeed no server software that I could find a bar one even has a default configuration sample that includes logging of source port.

M

So so somebody trying to do this is battling or pill. There's there's not even default for them to enable now.

M

The next point that I wanted to to raise with the existing recommendations is the existing recommendations, recommend that you log against some sort of traceable time source or some sort of central time source like an NTP server or something like that, but there's a whole plethora of deployment scenarios where that's not possible, and nor is it actually necessary for the requirement of the of the recommend of the BCP of the the best practice, which is to be able to identify enough information to be able to ask an ISP who was using this IP address at that time, because I'll take a moment to explain why you don't need to exact timestamp, it's pretty well-known in in the forensics world.

M

It's one that one of the first things you learn as a forensic examiner that you don't need to know the exact time which something happened at all you need to know is what time the time that was recorded and as long as the time is recorded consistent. You can offset the time then to be the real time. So if you--if, you are analyzing a computer, for example- and it's time is set one year wrong- you can look at the older times on those computer compared them to real times and then offset all the time.

M

So you you know, as long as time is recorded consistently, it doesn't need to be retorted recorded against a reference time. So I take exception with that point in in the recommendations in the current recommendations and then the last point that I wanted to UM to raise for for whatever it's worth, which is, logging information doesn't exist in a vacuum: people, log information for a reason and oftentimes people have all sorts of scripts and tooling, and so on. That's built based on their logs and by changing log formats.

M

You break existing tooling, so that data point for discussion. It's another challenge to the implementation of the recommendations. Next slide, please.

D

M

Okay, so I've only five minutes, so I just wanted to summarize and say, but the absence of primarily source port information in logs is a big problem from a crime attribution and a public safety point of view, and this was a point that was made by Europol in 2014 and repeated again in 2016 in their crime. I forget what the document is called: some sort of crime problems on the internet and and as I mentioned earlier, it doesn't logging of source port wouldn't make a crime attribution problem, go away what it does address.

M

The problem of these address sharing technologies to a certain extent, not in all scenarios, but to a certain. It certainly would improve things and I I'm, suggesting that the current best practice needs revision to address more of the practical issues with with locking source port. It's not just say, source ports should be logged, but also to make some. You know a more encompassing set of recommendations that can actually maybe help make it happen, and then last slide.

M

Please, and in order to move the discussion along I'm being completely new to engaging with the IETF I rolled up a document and I published it, which is now in its second draft and the link is there for anyone who wants to to read it or comment or my contact details are there and everything so, and so that was everything that I wanted to say. Thank you very much. Thanks.

A

So, where the time limit, but if people were willing to to ask questions and stay a couple of minutes longer I'm going to let the mic open.

D

A

D

Just a verbal question: it's a question of classification. You you are. Are you asking for this log in the just the network that implements the nuts or do you have also the same requirement from cells that implement the information processing, yeah.

M

That's a fantastic question and the answer is it's: the server's who are logging and not the nut and the nut itself, as I mentioned in my intervention in on Tom's talk, most people who are running and that are have a regulatory obligation to be able to identify. If, if a law enforcement agency comes to them and goes, who was using a particular IP address at a particular time, they have to be able to tell them. The problem is in cases of carrier-grade NAT.

M

If the law enforcement officer doesn't also have the time and the source port, they can't even ask the ISP. The ISP will say a million people were using that IP address at that time, or you know some large number of people and without the source port on the time stamp. We can't tell you so there's an information gap between the information, that's being protect aend in that cenar in psalm, carrier-grade NAT scenarios versus the information that is being retained at let's say, for example, a victim.

M

So, for example, if you were a website and your website got hacked, and you would like the person who hacked that website to be caught, if you don't have the source port on the time stamp, you don't stand a chance. The IP address is not enough. Thanks.

D

M

Education: okay, thanks.

P

A

P

I am I launched around I'm one of the authors of oxy 6302 and I. Take your point on the time stamp. Maybe the recommendation we made at the time was too restrictive, we'll be very happy to work with you to update the documents now about the other recommendation that you seems to be calling for.

P

It was not clear to me how they could be expressed in terms of things we could put inside of a updated version of a document that maybe we can have an offline conversation about that would be happy to work with you to update the document. Okay,.

M

And if I can just very briefly respond, I think what needs to be done in that respect is to broaden, perhaps the scope of the documents to include not only server recommendations for somebody, who's logging, a server but recommendations for people also who are implementing server software and people who are- and you know, and so that could include something like, for instance, server software should be able to log source port, and she.

G

M

Able to do it in a way that doesn't impact the performance of the server things like that when.

P

We wrote the document we were expecting that people were operating, the software will go talk to their vendors to do it. But apparently this has not happened or recommendation was not strong in us and maybe we can reward this. Yes, yeah.

M

And further, there are also scenarios for people who are writing in-house software and we're trying to comply with best practice might be interested in implementing the recommendations themselves. Not only vendors but also you know, end-users are who are writing their own software.

L

Microburbs so I've been successful in in using carrier-grade NAT port block allocation, so that one ipv4 address is shared by 16 people and I just say: okay, you want to know where that IPR is at that point of time. It's one of these 16. It's not millions. It's 16 and I mean police will immediately rule out most of them and I'll say it's one of these three and then then they have something go on. It have to be millions.

L

If you do the carrier great, not right, just spraying the connections of millions of users randomly across huge bases of ectopy for others it just doesn't work. Does anyone actually do that? It's never done the in one IP address well.

M

None obviously not millions, millions I'm being slightly facetious, but and I am aware that in I think it's in Belgium. They have a regulatory obligation to be only allowed to have 16 people right.

G

M

One IP address at a particular time, and but that's not the case everywhere and um and yes, I am aware of the situation in Belgium and that there are, and that has as how did I guess a positive side effect of they are now using ipv6. An awful lot more than carrier-grade NAT, but and ipv6 also, then comes with its own separate kind of worms. But that's another description and I'm.

A

Coming through so.

B

Yeah. Okay, sorry.

M

B

So, like responsible lady here so like I wanna, like not focus on the content of the graph at this point. Okay, so like the idea of presenting this here is to figure out if there's interest in updating 6302, like you know, Alan, maybe there's like stuff to be done and I want the working group to own that work. So that's the first step we wanna figure out like sit down and, like you know, ask the working group at some point like on the mailing list or if you wanna,.

G

B

Here, that's fine, but we are probably running out of time you're asking the mailing list like do. We won't have this date like 6302, to make it like more practical, so whatever changes then need to get done. So that's really what I wanted to get out of this saying like there's some feedback saying the recommendations we made are not practical, okay, so the question is we need to maintain our work. So that's really the reason I got like Dave to come and present here. Okay,.

A

I think, thanks in final lyric, everything.

C

This time a peach is considered of Belgium, it's not a regulation in Belgium at all. This is a voluntary code of conduct by eyes.

M

Yeah and other parties- that's okay, I didn't realize, I didn't know what the what the basis was, but I was aware. It was done in volume. Yeah thanks.

A

Okay, so thanks everyone for staying a few minutes longer thanks date for the presentation. Thank.

C

A

A

Do you have some more blue sheets somewhere there that you can pass by? Please.

L

A

Sure what they actually say.