On 6/30/2015 2:17 AM, Michael Welzl wrote: > >> On 30. jun. 2015, at 01.21, Joe Touch <[email protected]> wrote: >> >> +1 >> >> On 6/29/2015 4:06 PM, joel jaeggli wrote: >>> ignoring for a second the question of information leakage which is >>> apparently intentional in this case; an icmp message is unlikley to hash >>> onto the same path that the offending/failed flow would have been on in >>> many networks. >> >> When you say "middlebox" you're opening up the set that includes NATs, >> and that means any message that isn't to the same address/port pair >> isn't likely traverse the same path. > > - "might not take the same path all the way due to ECMP" is how I'd > put it. What makes you say "isn't likely to traverse the same path"?
If you're tracing back through other NATs, and you're on the public side at some point along the path, the ICMP cannot be translated. Further, if you're on the private side of a NAT with multiple IP addresses (e.g., CGN), again the ICMP cannot be translated. These are a property of some of the very middleboxes you're trying to reach, not of ECMP. >> So *at best* this might be able to contact the first middlebox it >> encounters, > > Not true in my office. Am I really the only one? This message can traverse from the private to the public side of any NAT with only one IP address, but cannot traverse into the private side of a NAT or from private to public of CGN. I'm guessing you're testing only cases where the latter doesn't happen. ... >> (I'm also ignoring the fact that most middleboxes don't want to admit >> they exist, so this might be only providing another way for them to >> ignore you) > > That's a strange argument: Middleboxes often want to appear invisible except for *their* purposes. I.e., you're sending them more information that they already ignore (and intend to ignore), IMO. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
