Can you please explain how a malicious node on your path truncating packets to 0x500 bytes is distinct from a 0x500 byte path MTU?

The distinction between this and a false ICMP packet is that a valid ICMP packet from a node in your path comes from a unauthenticated source. You can not generally distinguish this from a forged ICMP packet from a malicious entity not on your path.

In contrast, the model I propose results in the authenticated endpoint learning of the path MTU in a way that can only be altered by a node in the path refusing to send data beyond a certain size. The authenticated endpoint can then use a authenticated channel to feedback the data allowing the source to get authenticated path MTU information that could only come from the authenticated endpoint.

▲

zamadatix 8 months ago | parent [-]

> Can you please explain how a malicious node on your path truncating packets to 0x500 bytes is distinct from a 0x500 byte path MTU?

Sure, it doesn't even actually have to be truly in-path in all cases, though that makes things easier. I receive a copy of your message (be it I'm actually inline, tap, spoofed arp for a second, shared media, etc - pick your poison of the day) and I create a truncated version of that packet to send on the line. I don't even need to truncate every single one yet, since you haven't re-added the a probing mechanism like found in PLPMTUD to allow the MTU to be raised again yet :).

Putting all of the talk about the length authentication aside, I still don't see how the truncated headers was supposed to be an improvement over the ICMP approach of just sending the headers back as part of the payload. The ICMP destination unreachable message signaling the packet was too large already includes the original IP header + at minimum the first 8 bytes (though in practice RFC1812 increased that so you'll get significantly more) of data precisely so the client is able to map the request to the specific underlying session. If having the 5 tuple + identification number + TCP sequence number you sent match up with what you sent isn't already enough to trust it came from someone who got a copy of your message then you can add the HMAC anywhere in your headers without needing to replace the ICMP based signaling approach completely to get it sent back to you too? I guess because you want the message the message sent was too large to go to the remote side first instead of the sender?

▲

Veserv 8 months ago | parent [-]

You appear to be approaching my proposal as if it were a complete RFC intended to describe a complete end-to-end MTU discovery protocol. I am describing a primitive that can be used to efficiently implement MTU discovery. I did not describe probing because it is trivial to implement on top of that primitive in whatever way you so desire. A simple mechanism would be to just use your PLPMTUD mechanism, but instead of submitting continuously increasing packets, you can just submit a single large one and get the precise MTU in one step which is delivered back in whatever way (or equivalent) your PLPMTUD prescribes getting feedback.

You are describing a attack where somebody is either getting the unique copy of your packet by maliciously getting themselves into your path, at which point they can just drop all your packets and DoS you in a much more robust manner, or for some stupid reason you just send copies of packets to random malicious entities when they ask for it. I mean, I can imagine some knuckle-head designed a protocol and network where that is the case, but you should probably first not do something that stupid. Assuming you can not avoid it, you can still detect the case because if they can not interject into your actual path, the endpoint will receive both a authenticated packet and a authenticated truncated packet. In such a case, you can first of all just use the larger packet size since the larger size did get through. Second, you now know that somebody malicious or incompetent is getting a copy of your packets. I leave how you want to handle that up to the endpoints.

And, just as a aside, I did not mention this as I assumed it was obvious, but I believe you should still have a minimum MTU size no smaller than the current safe MTU. I am not arguing that somebody should be able to truncate you down to some egregiously small MTU. So worst case you just have to use the safe minimum MTU which is no worse than existing non-probing techniques. You could also just treat truncation as dropping if you have tons of malicious actors which defaults you to current probing techniques. My proposal can trivially fall back to the current models.

I disagree with ICMP signaling on multiple levels. First of all, you need to accept data from unauthenticated endpoints. Oh, but it is okay because they need to be on your path to get the uniquifiers. Oh, except you just pointed out how malicious actors can get copies so that is not true. You are now required to accept large amounts of data from malicious actors if you want to do ICMP based probing.

Second, I think having source addresses in headers is a design mistake and we should move away from protocols that demand it be present. We can do source authentication cryptographically which is more secure and prevents ossified middleboxes from engaging in layering violations or interfering with flows.

	▲	zamadatix 8 months ago \| parent [-]
		It's less about whether your proposal is ready to be submitted for standards track and more about pointing out alternative proposals always seem easier when you look at the primitive in isolation compared to a fully fleshed out solution in place today. But yes, I imagine the needed mechanism would be similar (if not identical to) the existing solutions deployed in PMTUD and PLPMTUD. Yes, such a person in your path is problematic for both solutions. The point is not that such a person is wholly unproblematic with the ICMP solution, it's that truncation provides no additional authentication in such scenarios as was claimed. If you can already assume a fully trusted and validated path without the possibility of anyone interfering then you don't really need to worry about spoofed ICMP either, not that the involvement of the MTU discovery algorithm had much to do it with that result. Pragmatically the answer here is one loses trust of any payload which is not whole and matching contained signatures, but that still remains true when one uses truncation instead. Agreed on minimally safe MTU, another case where truncation would not actually be providing a change from the current implementation. In regards to the discussion around the downsides of the current ICMP approach the claim is it's no less safe than truncation, not that it was more safe. Truncation was said to have brought authentication of packets claiming MTU change, in reality it provides the same level of veracity as ICMP in, yet again, a very similar manner. In regards to size of data to accept one needs to accept single ICMP destination unreachable type packets of up to 576 bytes to handle the MTU use case (other ICMP packet types and use cases may allow for more but you don't have to support that for handling MTU notifications). It's not an accident 576 bytes is also the minimum maximum packet size define for IPv4. This means the largest unauthenticated packet you need to parse is the same size as it would be in the truncation case: 1 of whatever the protocol defines as the minimum maximum packet size. Protocols without a cleartext source address (or much besides a destination address) in the header are definitely an interesting topic, and there are certainly use cases for this, but these really end up at the same kind of conversation except you get to skip the PMTUD portions and go straight to doing PLPMTUD inside the encrypted portion. With PLPMTUD inside the encrypted portion clients never have to listen to anything which came in a packet with an invalid signature. If one introduces truncation in this scenario you lose that as clients now need to also implicitly trust that a small packet with a broken signature was genuinely an MTU hint rather than a maliciously spoofed copy or whatnot. The only thing I'll say against such high secure protocols is they would not necessarily be something for everyone: they'd mandate a lot of things which may not be pragmatic for many use cases. E.g. when one wants to trade source anonymity for RPF protections. Or when one doesn't get value from encryption but gets value from load balancing/directing on header info in a high performance scenario. Or easy handling of multiple generations of protocols with opposing design goals in transport equipment. This is all to say I think such protocols would be valuable but I'd stop short of saying it's what IP needs to/should have done.