> On 30. jun. 2015, at 19.58, Joe Touch <[email protected]> wrote:
> 
> 
> 
> On 6/30/2015 10:54 AM, Michael Welzl wrote:
>> 
>>> 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.
> 
> It's a limitation; it might be useful to explain the limitation and why
> the remainder is still useful.

ok


>>> ...
>>>>> (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).
> 
> Sure. I'm just suggesting that you're working very hard to contact
> someone who doesn't want to pick up the phone. I'm not sure the effort
> will be worth the result.

Not working hard at all  :)   this is a very simple draft, it's just a packet 
carrying text! This doesn't change much for anyone and is harmless as can be, 
I'd say - so it might be worth trying. It could be useful (and I heard that 
confirmed by an ISP today). Happy to give up if folks think it's useless, but 
not because it doesn't go through the NAT on the other end or because it's not 
rate-limited. I don't mind putting recommendations in there! I mean, else 
someone could quickly send 100 "open the port, you twit !" messages and fill up 
the logfile, god beware  :-)   How in the world would we cope with that?   :-)

I'd like to hear from the ISP side... or middlebox maintainer side. Surely some 
folks from that side must be here - would you want such a thing or do you think 
it's useless? That's the only interesting question for this draft IMO

Cheers,
Michael

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to