> 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"? > 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? (and indeed in my office, the local person could only say "oh, that kind of blocking is above me, I wouldn't even know who to talk to") > but how useful would that be with that limitation? Even talking to the NAT can be useful, as lots of boxes do a lot of things at the same time these days. On my private wireless network my own wireless AP is my only NAT. That can let the ICMP message pass. My modem isn't NAT'ing me - so the next box is with my ISP, and whether the source port is the same or not, it's going through that box and that's probably the box I want to talk to. > (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: sending a message to someone is "providing a way for that someone to ignore me"? It doesn't make it easier to ignore me or anything like that - and it's fine to ignore. It doesn't require a response. Cheers, Michael _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
