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

[Michael Welzl <[e-mail]>]

> On 1. jul. 2015, at 20.49, 🔓Dan Wing <[e-mail]> wrote:
> 
> 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.

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 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
> 
> 
> On 01-Jul-2015 10:07 am, Michael Welzl <[e-mail]> wrote:
>> 
>> 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, [e-mail] wrote:
>>> 
>>> 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're collecting opinions on this - please let us have them   :-)
>>>> 
>>>> Michael
>>>> 
>>>> 
>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>> Resent-From: <[e-mail]>
>>>>> From: Michael Welzl <[e-mail]>
>>>>> Date: 30. juni 2015 kl. 00.35.39 CEST
>>>>> To: [e-mail]
>>>>> 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: <[e-mail]>
>>>>>> From: <[e-mail]>
>>>>>> To: Jianjie You <[e-mail]>om>, Michael Welzl
>>>>>> <[e-mail]>no>, Jianjie You <[e-mail]>om>, Michael
>>>>>> Welzl <[e-mail]>
>>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/int-area
>>>> 
>>>> _______________________________________________
>>>> Spud mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spud
>>>> 
>>> 
>> 
>> _______________________________________________
>> Spud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spud
> 
>