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

From: Michael Welzl <[email-masked]>
Date: Tue, 30 Jun 2015 00:35:39 +0200

Dear all,

We just posted the draft below. Not knowing which other group would fit, we're sending it here. We're really transport people and at least I am newbie to this group...  very curious to hear your thoughts:
- completely idiotic?
- exactly what the world has been waiting for?

... I guess it can only be one of the two above  :-)     If the chairs think that this makes sense to discuss in Prague, we'll be there, and I'd be happy to do a supershort presentation, but let us first hear what you think. It's a short and easy read, we promise that!  :-)

Thanks!
Michael & Janjie

> Begin forwarded message:
> 
> Resent-From: <[email-masked]>
> From: <[email-masked]>
> To: Jianjie You <[email-masked]>, Michael Welzl <[email-masked]>, Jianjie You <[email-masked]>, Michael Welzl <[email-masked]>
> Subject: New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt
> Date: 30. juni 2015 kl. 00.24.23 CEST
> 
> 
> A new version of I-D, draft-welzl-icmp-text-middleboxes-00.txt
> has been successfully submitted by Michael Welzl and posted to the
> IETF repository.
> 
> Name:		draft-welzl-icmp-text-middleboxes
> Revision:	00
> Title:		Text messaging to middlebox administrators using ICMP
> Document date:	2015-06-30
> Group:		Individual Submission
> Pages:		6
> URL:            https://www.ietf.org/internet-drafts/draft-welzl-icmp-text-middleboxes-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-welzl-icmp-text-middleboxes/
> Htmlized:       https://tools.ietf.org/html/draft-welzl-icmp-text-middleboxes-00
> 
> 
> Abstract:
>   This document describes the use of an ICMP message to send text
>   messages to on-path middleboxes from the endpoints.  The text message
>   is sent towards a destination but meant to be read by administrators
>   of middleboxes along the path to the destination.  The goal is to
>   improve the user's experience with simple middlebox cooperation.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 29 Jun 2015 16:06:35 -0700

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. While I can think perhaps more illustrative examples of
uses for a free form txt field (DMARC for example). the notion that
freeform txt messages with no source authetication should end up in a
ticketing system in an actionable fashion seems extrodinarily unlikely.

On 6/29/15 3:35 PM, Michael Welzl wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Jun 2015 16:21:48 -0700

+1

On 6/29/2015 4:06 PM, joel jaeggli wrote:
> 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.

So *at best* this might be able to contact the first middlebox it
encounters, but how useful would that be with that limitation?

(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)

Joe

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 30 Jun 2015 05:45:45 +0000

Hi Michael,

> ... I guess it can only be one of the two above  :-)     If the chairs think that this makes sense to discuss in Prague, we'll be there, and I'd be happy to do a supershort presentation, but let us…

Since you are requesting an ICMPv6 codepoint, I think 6man would be a 
better venue for this work if it progresses.

As for the draft itself, I have a few thoughts.

* It is unclear how the plaintext message ripples up to the 
administrator. Some clarity about this would be very useful.

* What about DoS attacks? There is no rate-limiting?

* Need to specify type>128 for IANA

* A +1 for Joel's and Joe's comments

Thanks
Suresh

---

From: Michael Welzl <[email-masked]>
Date: Tue, 30 Jun 2015 11:17:57 +0200

> On 30. jun. 2015, at 01.21, Joe Touch <[email-masked]> wrote:
> 
> +1
> 

- "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"?

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

> they exist, so this might be only providing another way for them to

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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 30 Jun 2015 11:22:32 +0200

> On 30. jun. 2015, at 07.45, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Michael,
> 

I thought about it before sending to intarea but I'm not sure: this is really not v6 "maintenance" - and this is really about ICMP in general, we only provided the spec for v6 up to now because that was faster for us to do (the draft says that future versions will include v4)

> administrator. Some clarity about this would be very useful.

Can be added. No problem I think.

> * What about DoS attacks? There is no rate-limiting?

We can insert a recommendation to not send this message too often FWIW  :-)  but I think this is just as "dangerous" as ICMP Echo Request or whatever. How often you process these messages / how many of them you process on a middlebox is really your own decision, it's always safe to ignore or drop.

> * Need to specify type>128 for IANA

ACK

> * A +1 for Joel's and Joe's comments

... but these were not convincing arguments at all I think.

Honestly if someone would tell me to go away because the idea of sending ascii around in ICMP is just plain silly, that'd seem to me to be a better argument than those  :-)

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jun 2015 10:03:03 -0700

On 6/30/2015 2:17 AM, Michael Welzl wrote:
> - "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.

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

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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 30 Jun 2015 19:54:53 +0200

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

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.e., you're sending them more information that they already ignore (and

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jun 2015 10:58:14 -0700

> 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 air…

It's a limitation; it might be useful to explain the limitation and why
the remainder is still useful.

> 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 wa…

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.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Tue, 30 Jun 2015 20:08:17 +0200

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

ok

> 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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 30 Jun 2015 18:31:47 -0400

Hi Michael,

On 6/30/15 2:08 PM, Michael Welzl wrote:
> 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

There are operational folks around, not sure how many hang around in
int-area.  You could run this through v6ops.  The only WG that has any
real relationship to middleboxes at this point is pcp (behave closed).
Given that PCP is defined to talk to middleboxes, you might get
reasonable feedback there.

Oh, and I am sure there are a few folks in the apps area who will have
things to say about carrying ASCII strings around.

Regards,
Brian