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

From: Michael Welzl <[email-masked]>
Date: Wed, 1 Jul 2015 18:26:16 +0200

Hi,

See below - this is remotely related to SPUD (really remotely, in that it addresses a human, but the human in control of a device of concern to SPUD).

We're collecting opinions on this - please let us have them   :-)

Michael

> Begin forwarded message:
> 
> Resent-From: <[email-masked]>
> From: Michael Welzl <[email-masked]>
> Date: 30. juni 2015 kl. 00.35.39 CEST
> To: [email-masked]
> Subject: [Int-area] Fwd: New Version Notification for draft-welzl-icmp-text-middleboxes-00.txt
> 
> 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
>> 
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: [email-masked]
Date: Wed, 1 Jul 2015 17:54:25 +0100

So, if there is no IP header in the payload, I have two questions:

(1) How do you verify the ICMP packet came from something on-path. rather
than being generated by a  random, potentially malicious sender? Why would
any host trust this?

(2) No header no encaps info - hence no ports or originating address etc?
- In other words not useful.

(3) Obviously this will not traverse NATs or tunnels (always a problem for
feed-backwards control messages), since these would not be able to
determine the next endpoint.

Gorry

> Hi,
>
> See below - this is remotely related to SPUD (really remotely, in that it
> addresses a human, but the human in control of a device of concern to
> SPUD).
>
>> 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?
>> ... 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:
>>>
>>> To: Jianjie You <[email-masked]>, Michael Welzl
>>> <[email-masked]>, Jianjie You <[email-masked]>, Michael
>>> Welzl <[email-masked]>
>>> 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:
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 1 Jul 2015 19:07:50 +0200

Answering all three issues in one go:

It's intended to reach the first, maybe second hop. There you can either verify where it came from by considering the physical interface, or (more likely I think) you can "trust but verify"  ;-)   (since we're on the SPUD list)

Indeed these text messages are only meant as hints.

Consider this use case in the draft:

"This is Michael Welzl, sitting in office 4164 at IFI.  I want to run
   videoconferencing software XY that I need for a project I'm in, but
   it doesn't seem to work.  I think you blocked some UDP ports there.
   Not good, please fix and get back to me."

=> this is a request to check for port usage of a videoconferencing software. Depending on whether the box admin believes this software should be supported or not, (s)he might accept that hint and check. (yes it opens for interesting denial of service attacks: "port X is blocked!" "no, actually, port Y!" "please check port Z now!" - haha...    in which case you might want to check against the source, based on your physical network setup.

Unless you see a sequence of contradicting messages, it might be worth a check. Consider the other use case:
"Hello, I like the WiFi that's being provided at this airport!  But
   did you notice that there is almost no reception near the C gates in
   terminal 3?"

No way for an attacker to find out if you got the message or if you care about it. So, one solution is: read the messages with some delay, maybe daily. If there is an indication of an attacker sending you back and forth between A, B and C gates, don't believe it.

In other words: it's just an unreliable & advisory text message, and - as with road signs etc. - attacks can be counteracted by common sense  :-)

Michael

> On 1. jul. 2015, at 18.54, [email-masked] wrote:
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 1 Jul 2015 11:49:21 -0700

I don't see high likelyhood of someone typing (or speaking) a message like that, pointing out a problem that might or might not get heard and result in action.

I could see an application or OS spitting out messages, though -- but probably not in the format proposed.  For example, it could be valuable for a network administrator to know that their users want to use SRTP-over-UDP, but UDP is being blocked forcing users to use SRTP-over-TCP (which has a different -- sometimes worse -- user experience than UDP).  A browser might want to use QUIC-over-UDP, and it could be useful to tell the network administrator that it was forced to fallback to TCP.  An OS might want to use native SCTP, native IPsec (protocol 50), or native QUIC or native RTP (QUIC and RTP are not IANA registered as protocols on top of IP, but by all rights they could / should be).  Another complaint message might be "Gosh, I need IPv6" or "I need NAT64".  If the "complaint" messages were to be computer-parsable, I see more value in your proposal.  I'm not too keen on ICMP for this communication, though; perhaps HTTP POST to a well-known FQDN, such as complaint.local, and some sort of structure to what is posted could be more valuable.

-d

---

From: Michael Welzl <[email-masked]>
Date: Thu, 2 Jul 2015 00:17:50 +0200

> On 1. jul. 2015, at 20.49, 🔓Dan Wing <[email-masked]> wrote:
> 

Well... I can imagine you're right but how to know before trying?

> I could see an application or OS spitting out messages, though -- but probably not in the format proposed.  For example, it could be valuable for a network administrator to know that their users wa…

Funny that you mention this - I was actually planning to include a "use case" on such automated messages but just forgot. I agree that's perhaps the most useful case.

But I wonder, why wouldn't ascii be computer-parsable? I can't imagine trying to agree on a common "complaint format", so I guess ascii is as good as anything... maybe then applications would begin to send messages in a certain style? That style could develop... be defined elsewhere?  Anyway we could make a start, differentiate between computer-parsable and human messages, and require a certain base format to start with...  if others see value in that too?

As for ICMP being the carrier, I don't mind & I'm open to ideas. Hard to know what's best to use to communicate with a box that drops some of your stuff, really.
The HTTP POST idea is interesting. I personally prefer sending a packet to the actual destination where the problem happened and expecting it to be read by boxes on the path though - because the person you want to reach MAY be local, but it MAY also be a few hops away?!

Cheers,
Michael

---

From: "Black, David" <[email-masked]>
Date: Thu, 2 Jul 2015 22:02:27 +0000

> But I wonder, why wouldn't ascii be computer-parsable? I can't imagine trying
> to agree on a common "complaint format", so I guess ascii is as good as
> anything... maybe then applications would begin to send messages in a certain
> style? That style could develop... be defined elsewhere?  Anyway we could make
> a start, differentiate between computer-parsable and human messages, and
> require a certain base format to start with...  if others see value in that
> too?

Pick your favorite log format - most log analysis tools out there have learned
to extract information from all the "ususal suspects" as there are no really
well-defined standards that can be relied upon.

Thanks,
--David

> -----Original Message-----
> From: Spud [mailto:[email-masked]] On Behalf Of Michael Welzl
> Sent: Wednesday, July 01, 2015 6:18 PM
> To: 🔓Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Spud] [Int-area] New Version Notification for draft-welzl-icmp-
> text-middleboxes-00.txt
> 
> 
> > I don't see high likelyhood of someone typing (or speaking) a message like
> that, pointing out a problem that might or might not get heard and result in
> action.
> 
> > I could see an application or OS spitting out messages, though -- but
> probably not in the format proposed.  For example, it could be valuable for a
> network administrator to know that their users want to use SRTP-over-UDP, but
> UDP is being blocked forcing users to use SRTP-over-TCP (which has a different
> -- sometimes worse -- user experience than UDP).  A browser might want to use
> QUIC-over-UDP, and it could be useful to tell the network administrator that
> it was forced to fallback to TCP.  An OS might want to use native SCTP, native
> IPsec (protocol 50), or native QUIC or native RTP (QUIC and RTP are not IANA
> registered as protocols on top of IP, but by all rights they could / should
> be).  Another complaint message might be "Gosh, I need IPv6" or "I need
> NAT64".  If the "complaint" messages were to be computer-parsable, I see more
> value in your proposal.  I'm not too keen on ICMP for this communication,
> though; perhaps HTTP POST to a well-known FQDN, such as complaint.local, and
> some sort of structure to what is posted could be more valuable.
> 
> Funny that you mention this - I was actually planning to include a "use case"
> on such automated messages but just forgot. I agree that's perhaps the most
> useful case.
> 
> But I wonder, why wouldn't ascii be computer-parsable? I can't imagine trying
> to agree on a common "complaint format", so I guess ascii is as good as
> anything... maybe then applications would begin to send messages in a certain
> style? That style could develop... be defined elsewhere?  Anyway we could make
> a start, differentiate between computer-parsable and human messages, and
> require a certain base format to start with...  if others see value in that
> too?
> 
> As for ICMP being the carrier, I don't mind & I'm open to ideas. Hard to know
> what's best to use to communicate with a box that drops some of your stuff,
> really.
> The HTTP POST idea is interesting. I personally prefer sending a packet to the
> actual destination where the problem happened and expecting it to be read by
> boxes on the path though - because the person you want to reach MAY be local,
> but it MAY also be a few hops away?!
> 
> Cheers,
> Michael
> 
> 
> >
> > -d
> >
> >
> >> It's intended to reach the first, maybe second hop. There you can either
> verify where it came from by considering the physical interface, or (more
> likely I think) you can "trust but verify"  ;-)   (since we're on the SPUD
> list)
> >>
> >> => this is a request to check for port usage of a videoconferencing
> software. Depending on whether the box admin believes this software should be
> supported or not, (s)he might accept that hint and check. (yes it opens for
> interesting denial of service attacks: "port X is blocked!" "no, actually,
> port Y!" "please check port Z now!" - haha...    in which case you might want
> to check against the source, based on your physical network setup.
> >>
> >> No way for an attacker to find out if you got the message or if you care
> about it. So, one solution is: read the messages with some delay, maybe daily.
> If there is an indication of an attacker sending you back and forth between A,
> B and C gates, don't believe it.
> >>
> >> In other words: it's just an unreliable & advisory text message, and - as
> with road signs etc. - attacks can be counteracted by common sense  :-)
> >>
> >> Michael
> >>
> >>
> >>

---

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

ok

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

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

---

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

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

Ah, sorry, I saw this one too late - it answers a question I ask in my previous answer  :(