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

Eric Rescorla <ekr@rtfm.com> Fri, 26 January 2018 21:58 UTC

Return-Path: <ekr@rtfm.com>
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 8F39E129C6E for <mboned@ietfa.amsl.com>; Fri, 26 Jan 2018 13:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 G5d7QlIgENku for <mboned@ietfa.amsl.com>; Fri, 26 Jan 2018 13:58:49 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C7F127909 for <mboned@ietf.org>; Fri, 26 Jan 2018 13:58:45 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id q6so721943ywg.3 for <mboned@ietf.org>; Fri, 26 Jan 2018 13:58:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ylT/ABri9sF96FXr2vx1E2N0+/DP80+MC9EJhIXWaTE=; b=huBrOCFNVGMhw59no9/yjF/ofzVm5Julz5RZ2Yu0MDqtXPTRX2MsIiWA1kKT5d0fqJ iF+DFgyFdrZwCVCgEkCt/YJdek8uID9cD/tQjlIkjvjzqFkJkHfyoBrbVyudXhexObRu S5dUHtRFoNIEvhSuC6KJA/MC+OrkAQ9uhEwLBlDXIoXCEqR8yLaIYHswINFdBdWisXJP 8F4V/JfjgMVqP73hmsg5qn2Q/4OxN9rtG0R6QPvSg5V6hkjGJX9Y+zWm1FFdTB2GAVSR ovqcSJQ/UhsQ1HvzjiK2/9Dwv5e8KCiN6DQ/hhuuQr0yXCxuBoSAUAn+I556ioLv+WzA XWMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ylT/ABri9sF96FXr2vx1E2N0+/DP80+MC9EJhIXWaTE=; b=ncFLIkrwPCP1aqRVYZBMoDWf7Ri249qHgOpd1s5w0c9efp02j49QaWBdJe22n9uS2n X2fa/f2ECNo5069YmbxSLBioszFfZAyJWQoKoF/CwILuLu6narXingx0DsYpsjZbisDY sUZDQY/Td3zxzC+1ST2sy5Wl0nvGqL2gWpsipk4hi3iVW0oAA+npLgN1mmlJ0xDYbzzd w2iZuQ8vBvQdcDH0CsxemiD7X4BSh0w+YJ0A4ZHKg7cYZttOcbTL10ikjPNLfkTnDZf4 wK4Pr9sqneKW8EUaR458axxiKueY84dQK5M9aX79HWA8PN/TQ3HJua659b6L8qNr0GoQ 0xnw==
X-Gm-Message-State: AKwxytcNoVat+Jpsj0JoVIEo7vCPDQG2XCsLDFn0LjfFSmd+f/WR7LWo 5azlNEnjo9ak/bux9uTUk0Ge+AE5/oDcq5eTnvmx/w==
X-Google-Smtp-Source: AH8x22629S1npo3GrRryakzfAZgBxXID/OSLdgjzKH8kxgzq+bcydRjtVZCuAZxHsq+psOoJ75s5WKOriEtcH9yXXhc=
X-Received: by 10.13.226.194 with SMTP id l185mr12733119ywe.47.1517003924603; Fri, 26 Jan 2018 13:58:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.160.201 with HTTP; Fri, 26 Jan 2018 13:58:04 -0800 (PST)
In-Reply-To: <20180126013118.GD16477@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> <20180125223335.GA16477@faui40p.informatik.uni-erlangen.de> <CABcZeBPbCJfP=VVC6irEUtbiFuQgmMCQMEUBern=kAG-KP1SQQ@mail.gmail.com> <20180126013118.GD16477@faui40p.informatik.uni-erlangen.de>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 26 Jan 2018 13:58:04 -0800
Message-ID: <CABcZeBN5dWkn7dGZ00tw2AkGPPAdfS+C_8mrVMuB9efc4o1a9Q@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: The IESG <iesg@ietf.org>, draft-ietf-mboned-mtrace-v2@ietf.org, mboned@ietf.org, mboned-chairs@ietf.org
Content-Type: multipart/alternative; boundary="001a114fc3d60ca04b0563b500db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/12va59Q2HlzFfBJ-gmuQ6GzMm64>
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: Fri, 26 Jan 2018 21:58:51 -0000

Hi Toerless,

I appreciate the solution thinking, but I don't want to overrotate on these
specific threats (though of course we must address them). My concern is
that if there are threats this obvious then we need a more complete threat
analysis. I.e., what are the avenues for attack with this protocol and then
what mechanisms prevent those things. The purpose of the security
considerations section is to make sure that that happens. Has someone done
that somewhere and it just didn't make it into the document?

-Ekr


On Thu, Jan 25, 2018 at 5:31 PM, Toerless Eckert <tte@cs.fau.de> wrote:

> On Thu, Jan 25, 2018 at 03:08:58PM -0800, Eric Rescorla wrote:
> > > My point B.1) explicitly disables lying about the requesting address,
> so
> > > it is explicitly meant to prohibit amplification attacks.
> > >
> >
> > I don't see how that's true. The attack I am concerned about is that you
> > forge a *Request*, not a *Query*. And because the request indicates the
> original
> > requester.
>
> Ah, sorry. I thought to remember that the text from you said query.
> I just replied for query messages so far.
>
> > (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).
> >
> > Sorry, I'm not seeing this. The point is that you pretend to be a router
> > that is forwarding a Request and fill in a bogus Client Address field.
> Waht
> > stops that.
>
> In practical deployments IMHO we can only reasonable get similar solutions
> to
> what customer are also willing to deploy with PIM. For 99% deployments that
> is configured classificatio of interfaces as trusted/inside-clamshell or
> untrusted/user-facing, and on the untrusted interfaces you don't accept
> requests, just queries. And apply the suggested B.1 policy (Mtracev2 Client
> Address must be connected on receiving interface).
>
> It might still be useful to have mtrace prepared for customers protecting
> it
> with IPsec - without requiring special features in mtrace or IPsec for it.
>
> IMHO for that, we need to have one UDP port for mtrace NNI messages
> (requests), and another for UNI messages (query, response).
> That would allow customers to take a vanilla IPsec implementation and
> protect
> the mtrace NNI messages and therefore eleiminate interface clamshell
> classification.  In multicast signaling we got this for free: PIM is NNI,
> IGMP/MLD UNI. Easy to distinguish for IPsec.
>
> > > 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 question is whether those options are in fact adequate. For the
> reasons
> > above I don't believe that.
> >
> > -Ekr
>
> Cheers
>     Toerless
>
> >
> >
> > >
> > > 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
>