Continuing inline: Am 07.11.24 um 00:03 schrieb Ron Bonica:
Including the WGJuniper Business Use Only ------------------------------------------------------------------------ *From:* Ron Bonica <rbon...@juniper.net> *Sent:* Wednesday, November 6, 2024 4:01 PM *To:* Rolf Winter <rolf.win...@hs-augsburg.de>*Subject:* Re: [Int-area] Re: Reverse Traceroute - Open Issue 1: Encoding (Rolf Winter)Rolf, Inline [RB] Ron ------------------------------------------------------------------------ *From:* Rolf Winter *Sent:* Wednesday, November 6, 2024 1:18 PM *To:* Ron Bonica*Subject:* Re: [Int-area] Re: Reverse Traceroute - Open Issue 1: Encoding (Rolf Winter)Ron, see inline. Am 06.11.24 um 18:12 schrieb Ron Bonica: > Rolf, > > I do not think that legacy middlebox behavior is a good reason to change > existing PDU semantics. The following are rationale: > > 1. > We may be subverting the purpose of the middle box. Some middleboxes > are firewalls. Assume that a network operator doesn't want reverse > traceroute traffic in their network until they have had time to > evaluate it. By making reverse traceroute traffic indistinguishable > from PING (at least to legacy middlebox), we sneak past the > network's defenses. That is not correct. It is distiguishable, since the codes are different and we would register those with IANA. We are not hiding the fact that is is different. Also, since the ICMP code is in a fixed location, this could be filtered in HW efficiently.[RB] Please read the statement above. I said that "By making reverse traceroute traffic indistinguishable from PING (at least to legacy middlebox), we sneak past the network's defenses. This is most definitely true! Legacy middleboxes have no idea what the new codes mean. They probably don't even examine them[RB] You proved that point by making reverse traceroute traffic look so much like PING that it snuck past middleboxes.
You mentioned firewalls in your original message, but we _only_ measured NAT-Router implementations (home gateways to be precise). Firewalls and routers are two different beast altogehter. A NAT router is simply forwarding packets and I can see that implementors choose a shortcut to only look at the ICMP type as the device's function will just work. A firewall is a security device and ICMP is extensible by type _and_ code. If a vendor decides to only look at the type, then that is an error on their side. Should we design protocols based on potential errors of network device vendors? I would say no. So we showed that this will work through a lot of NAT implementations (and I would characterize that as positive) and we cannot make any assumption based on that data what firewall implementations would do.
> > 2. > We are setting a bad precedent. If we change the semantics of an > existing PDU every time we need a new function, semantics will > become overloaded sooner or later. Do we want to face that painful > situation in the future, or do we want to gepeople in the habit of > keeping their middleboxes up to date now. > I would disagree. We use different codes, so this is a different PDU. Also, if we argue along those lines, we probably would need to go down a different route altogher and use a completely new type, i.e. also not use Extended Echo.[RB] I see that you have not yet written the section that talks about how your draft updatesRFC 792 or RFC 8448. Let's talk again after you have written that section. > 3. > We may remove what little motivation operators have to keep their > middle boxes up to date. This is speculation at best and I don't see that at all. [RB] So, what motivation would remain?
What motivation are we taking away? Why would a vendor choose not to update their box because of reverse traceroute?
Best, Rolf
Ron Best, Rolf > > > Ron > > > > > > > Juniper Business Use Only > > > _______________________________________________ > Int-area mailing list -- int-area@ietf.org > To unsubscribe send an email to int-area-le...@ietf.org _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
