> On 30. jun. 2015, at 19.03, Joe Touch <[email protected]> wrote: > > > > 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.
Got it now, sorry for the confusion. So I don't really care much about the middlebox behind a NAT on the other side - it's *my* side I care about. The usage examples in the draft refer to talking people in my institution or at the airport where I'm sitting. I don't expect to be (or care about being) able to talk to a middlebox far, far away... chances are, the message is dropped long before anyway. > ... >>> (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. Still a strange argument :-) I can send them 100 other more things that they can ignore, how is that making anything worse? Could be a router, could be some administrator at the first-hop border router of my ISP, could be a person trying to run a public network at a conference or in an airport ... all these people I want to try to reach. Some of them have an interest in hearing feedback which they now can't get (at an airport, I wouldn't know who to talk to and wouldn't want to go around and ask, so why bother - but sending a short message is really not so painful). Cheers, Michael _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
