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

["Black, David" <[e-mail]>]

> 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:[e-mail]] On Behalf Of Michael Welzl
> Sent: Wednesday, July 01, 2015 6:18 PM
> To: 🔓Dan Wing
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Spud] [Int-area] New Version Notification for draft-welzl-icmp-
> text-middleboxes-00.txt
> 
> 
> > 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
> >
> >
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud