Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)

Toerless Eckert <tte@cs.fau.de> Thu, 25 January 2018 22:33 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA40912D7E3; Thu, 25 Jan 2018 14:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3SUvLCHtXu5; Thu, 25 Jan 2018 14:33:40 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E3712AF77; Thu, 25 Jan 2018 14:33:40 -0800 (PST)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A3E2658C56D; Thu, 25 Jan 2018 23:33:35 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 88A06B0D87B; Thu, 25 Jan 2018 23:33:35 +0100 (CET)
Date: Thu, 25 Jan 2018 23:33:35 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-mboned-mtrace-v2@ietf.org, mboned@ietf.org, mboned-chairs@ietf.org
Message-ID: <20180125223335.GA16477@faui40p.informatik.uni-erlangen.de>
References: <151628969901.2325.7724014542086691903.idtracker@ietfa.amsl.com> <20180119193149.GA26689@faui40p.informatik.uni-erlangen.de> <CABcZeBNDqq_5XPad76WrsrN_JS2J1iAAC068=y0Nq12SKJOQ=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBNDqq_5XPad76WrsrN_JS2J1iAAC068=y0Nq12SKJOQ=Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/ZmAtTUlXeIjCUq_asl57PX6hwV8>
Subject: Re: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2018 22:33:44 -0000

Thanks Eric, inline

On Wed, Jan 24, 2018 at 02:20:10PM -0800, Eric Rescorla wrote:
> On Fri, Jan 19, 2018 at 11:31 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> > [no comment needed]
> This doesn't seem like a good reason to create significant security issues
> for the rest of the Internet.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I should say "no comment", but actually, this could help to consider:

Please tell me a place (ISP) where i can get residential IP Multicast across
the Internet so i can move there.

Aka: 99.9% of IP Multicast is deployed in controlled networks. 99.9% of
IP multicast application traffic is failing IETF congestion control requirements
and does not care because they operate in controlled networks. If you have
any market investing, your financial gains likely depend on non
IETF congestion control compliant IP multicast trading traffic.

Aka: not my preference (i have written my preferences in B.1/2/3), but if we are
not coming up with any better security scoping, we might consider scoping
mtrace to controlled networks because it would effectively not limit its
deployment much at all.

> > B.1) deny third-party mtrace for user devices by default
> >
> > | Mtrace queries SHOULD by default only be processed when sent with a
> > source
> > | address directly connected to the interface on which it is received. They
> > | MAY additionally be filtered by the presence of IGMPv3/MLDv2 explicitly
> > | tracked receiver state for the indicated multicast traffic (group
> > {,source})
> > | from the source address.
>
> I think the key point here is that this is not solely about unauthorized
> access  but also about amplification. To expand on that point, another source of
> potential  amplification is to inject a Request but to lie about the requesting
> address,  thus causing the final router to send a big response.

My point B.1) explicitly disables lying about the requesting address, so it is
explicitly meant to prohibit amplification attacks. 

(give or take the subnet local limitations and/or additional L2 security
 required to prohibit intra-l2-lying that i mentioned in my original mail).

> > Give or take the wording, but would these three items if worded according
> > resolve your discuss ? To re-summarize:
> >
> >   B.1) deny third-party mtrace for user devices by default
> >   B.2) explicit permitting third-party mtrace only to trusted
> >        (OAM equipment) originators
> >   B.3) Expectation/setup of non on-path spoofing between third-party
> >        (OAM device) query initiator and responder.
> >
> > C) I hate address filtering security, but given how this has been a
> > protocol waiting for 20++ years for an RFC i don't think we should
> > muck around with the protocol now and further delay it. Aka: as
> > nice-to-have larger query-ids would be - is it worth doing this
> > protocol change now given the above security model ?
> 
> I'm not sure how long this is waiting is really that persuasive an argument
> against doing the right thing. We know addresses are untrustworthy and
> it's not like I'm suggesting you introduce real comsec between the
> endpoints (though some form of real authentication would clearly be
> better).

If i am identifying the right part of your original email, your suggestion was:

> It seems like many of the issues I raise above would be fixed or at                                           
> least mitigated by having some sort of access control mechanism. 

My points B.1, B.2, B.3) provide solid access control mechanisms for
mtrace using mechanisms that are the most widely adopted form of security in ISPs
and that this option of security in mtrace should not be dismissed just because
it took us so long to bring the protocol in front of IESG review even if we agree
that we should have better options beyond that.

The other point was that better security options are something we should not
invent as one-off protocol hack sinto mtrace (even if some mtrace none request/reply
messages might be fun to define) but instead we should adopt solutions that are more
likely in-line with existing network OAM security strategies. TLS connections,
netconf/yang etc. pp. As i described in my email.

Cheers
    toerless

> -Ekr
> 
> 
> 
> The most likely next step to overcome the trusted path issue between
> > query initiator to query responder is to make an mtrace yang model where
> > you can actually initiate an mtrace via netconf/yang, aka: replace
> > the query with netconf. Like you would today just ssh into the
> > LHR and run a local mtrace client there.
> >
> > Alas, i see no easy way to get back to support A) in a lightweight
> > fashion ;-(
> >
> > Cheers
> >     Toerless
> >
> > On Thu, Jan 18, 2018 at 07:34:59AM -0800, Eric Rescorla wrote:
> > > Eric Rescorla has entered the following ballot position for
> > > draft-ietf-mboned-mtrace-v2-22: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to all
> > > email addresses included in the To and CC lines. (Feel free to cut this
> > > introductory paragraph, however.)
> > >
> > >
> > > Please refer to https://www.ietf.org/iesg/stat
> > ement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > >
> > > The security considerations of this document are inadequate. My review
> > > turns up at least the following potential issues which do
> > > not seem to be addressed or even discussed:
> > >
> > > - Amplification: this protocol does not appear to verify that the
> > >   sender of the query actually owns the IP it claims. Because
> > >   responses are much larger than queries, this allows for an
> > amplification
> > >   attack, especially if the client is able to send a query that elicits
> > >   multiple replies. One defense here would be to fill the rest of the
> > packet
> > >   with zeroes, thus somewhat reducing the amplification factor. Access
> > >   control would also help.
> > >
> > > - Forgery of responses: because the query id is so short, an attacker
> > >   can generally produce a message which has a nontrivial chance of
> > >   corresponding to an extant query. This could be addressed by having
> > >   a query ID that was large and random.
> > >
> > > - Anyone on-path can forge responses.
> > >
> > > In addition, Section 9.4 seems inadequate. Isn't it generally the case
> > that
> > > who is sending to who is sensitive? This seems like a fairly serious
> > privacy
> > > obstacle to using this protocol at all.
> > >
> > > It seems like many of the issues I raise above would be fixed or at
> > > least mitigated by having some sort of access control mechanism.  I
> > > understand why it might be the case that it's not practical to have
> > > full communication security between the links (though it would of
> > > course be desirable), but it's not clear to me why arbitrary people
> > > should be allowed to instantiate queries.
> > >
> > >
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > >
> > > S 1.
> > >    When an Mtrace2 client initiates a multicast trace, it sends an
> > >    Mtrace2 Query packet to the LHR or RP for a multicast group and,
> > >
> > > This seems a bit confusing as there are multiple LHRs for the group.
> > > Can you rephrase?
> > >
> > >
> > > S 2.1.
> > >    ALL-[protocol]-ROUTERS group
> > >       It is a link-local multicast address for multicast routers to
> > >
> > > This is grammatically funny. Perhaps remove "It is"
> > >
> > >
> > > S 3.
> > >    additional information associated with the message.  If an
> > >    implementation receives an unknown TLV type for the first TLV in a
> > >    message (i.e., the header TLV), it SHOULD ignore and silently discard
> > >    the entire packet.  If an implementation receives an unknown TLV type
> > >    for a subsequent TLV within a message, it SHOULD ignore and silently
> > >    discard the entire packet.
> > >
> > > ISTM that these cases are handled identically so is there a reason
> > > not just to remove the first sentence and change the second one to
> > > "for any TLV"/
> > >
> > >
> > >
> > > S 3.2.1
> > >    An Mtrace2 Query is usually originated by an Mtrace2 client which
> > >    sends an Mtrace2 Query message to the LHR.  When tracing towards the
> > >    source or the RP, the intermediate routers MUST NOT modify the Query
> > >    message except the Type field.
> > >
> > > I'm not sure I follow this. Don't routers either (a) not touch this at
> > all
> > > or (b) if they are the LHR, change Type from Query -> Request and then
> > > add a response block? This text seems to not really capture either case.
> > >
> > >
> > > S 3.2.4.
> > >       Note that Mtrace2 does not require all the routers on the path to
> > >       have synchronized clocks in order to measure one-way latency.
> > >
> > > It's not clear to me how one does this. Can you expand?
> > >
> > >
> > > S 3.2.6.
> > >
> > >           0x01    # of the returned Standard Response Blocks
> > >
> > > Nit: Do you want to say 0x0001
> > >
> > > Also, an example of the case covered by this section would help, I think.
> > >
> > >
> > >
> > > S 4.4.
> > > It might be clearer to move this up a bit in the text as it sort of
> > > summarizes some cases you already covered before. It would be easier
> > > if it provided an overview instead.
> > >
> > >
> > > S 5.9.
> > >
> > >    In this case, the Mtrace2
> > >    client may receive multiple Mtrace2 Replies from different routers
> > >    along the path.  When this happens, the client MUST treat them as a
> > >    single Mtrace2 Reply message.
> > >
> > > Can you please describe how the client reassembles multiple messages
> > > into one. I think I may know how to do this, but the document should
> > > tell me.
> > >
> > > S 8.
> > >    The following new registries are to be created and maintained under
> > >    the "RFC Required" registry policy as specified in [4].
> > >
> > > Why did you choose RFC Required rather than Specification Required?
> > > This just seems to unduly put load on the ISE.
> > >
> > >
> > > _______________________________________________
> > > MBONED mailing list
> > > MBONED@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mboned
> >
> > --
> > ---
> > tte@cs.fau.de