Subject: Re: [Int-area] New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 1 Jul 2015 07:20:28 +0000

FWIW, as I am rather sure the ISP guy Michael mentions is yours truly, let me say that I have been working for commercial providers, where strongly structured procedures could make more difficult for this mechanism to work (though we should not neglect cumulative effects), and for the academic networking environment, where something like a text message could have real short-time effects...

Be goode,

On 30 Jun 2015, at 20:08 , Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:

On 30. jun. 2015, at 19.58, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

On 6/30/2015 10:54 AM, Michael Welzl wrote:

On 30. jun. 2015, at 19.03, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

On 6/30/2015 2:17 AM, Michael Welzl wrote:

On 30. jun. 2015, at 01.21, Joe Touch <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Black, David" <[email-masked]>
Date: Thu, 2 Jul 2015 20:07:21 +0000

> >> 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.
> >

And specify boundaries at which these text messages SHOULD be dropped because
they are likely to be irrelevant beyond that point.  For the airport or
university example, this may be where the airport or university network hands
off to the ISP that provides connectivity to the Internet.

I also concur with Joel's and Diego's observation that an operator with strongly
structured procedures (e.g., ticketing system) is going to have some difficulty
dealing with this sort of problem report, especially as it's unauthenticated -
the fact that one can get an ICMP packet into the operator's network does not
automatically entitle one to draw upon the operator's support resources.

Thanks,
--David

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Michael Welzl
> Sent: Tuesday, June 30, 2015 2:08 PM
> To: Joe Touch
> Cc: [email-masked]
> Subject: Re: [Int-area] New Version Notification for draft-welzl-icmp-text-
> middleboxes-00.txt
> 
> 
> > On 30. jun. 2015, at 19.58, Joe Touch <[email-masked]> wrote:
> >
> >
> >
> >>> On 30. jun. 2015, at 19.03, Joe Touch <[email-masked]> wrote:
> >>>
> >>>
> >>>
> >>>>> On 30. jun. 2015, at 01.21, Joe Touch <[email-masked]> wrote:
> >>>>>
> >>>>> +1
> >>>>>
> >> 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.
> >
> >> 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).
> >
> 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
> 
> [email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Fri, 3 Jul 2015 00:13:07 +0200

[ + spud list ]

> On 2. jul. 2015, at 22.07, Black, David <[email-masked]> wrote:
> 

ok

> automatically entitle one to draw upon the operator's support resources.

This was also said by Diego Lopez - such operators may just not be a suitable target for this type of message (rather, smaller ones, then). But "entitle to draw upon the resources" is a bit exaggerated when we're talking about sending an ascii message. Nobody's obliged to listen to it, after all.

Anyway, I have to say I'm getting some very good feedback here - in particular, I like Dan Wing's observation (on the spud list) that applications could auto-generate this (e.g. "Tried QUIC but failed UDP, falling back to TCP"); he suggested a machine-parsable format but now I wonder how to do this?

All of a sudden, this seems to become more reasonable and make more sense than I ever expected   :-)

Thanks!
Michael