Including the WG
Juniper 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.
>
> 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 updates
RFC 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?
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
