Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-p2mp-bfd-08: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 24 January 2018 21:03 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BEA129C6B for <trill@ietfa.amsl.com>; Wed, 24 Jan 2018 13:03:31 -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 azegB2p_4uBc for <trill@ietfa.amsl.com>; Wed, 24 Jan 2018 13:03:29 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 DBA57129C5D for <trill@ietf.org>; Wed, 24 Jan 2018 13:03:25 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id u21so2030929ywc.2 for <trill@ietf.org>; Wed, 24 Jan 2018 13:03:25 -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=ImiohdUFuQjLms0OUSWTKS5P7bU4WrBvQrsD4gfCxhc=; b=XwZJZ23p3ZC9aMywngZNCdN4vWtkqW/BAgf4Ve74g2JnmZ55eZ/5G3Xn9z/jh+et4S vKyp0lNrftcIbt+FOivuCQ2GvrsCv8EK2QQV7sHfrmQYuxuk4E0yWkdpeY0GXngdmmwR n+hoHSwoBXQ5Vjt95r7fGtElf1La3yEaeI+sJ5F44NyH3Zb6OWXHOFzBI3sqYo30RJPR x10w7AlemdVhq/e00bSpIAw/Cze78D4AWWYvZycFDqJ/9NNF+SPKr/uHxnC9OAe5Fa7x QXi3/S4SmiSW2pRis7fgng6PwyL5F1qsJxr1DNull6Qa3qXDrzBNWj5P53OXK+JqZoRM Xwkg==
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=ImiohdUFuQjLms0OUSWTKS5P7bU4WrBvQrsD4gfCxhc=; b=nSAGLt9saLaMJ1x9m2ct2ct/9zXe5rn1qZlDwzpm3gFb9qG6ViMuNygX2DmkETM/GS jZwsSdujpHEuLStURoiRavLUthld8GGJz2djpYtnmIcZ+nUwzJqLKv+wfgAmr/llPMoh xefbbWLRMuj1dkKPYI99Mn5+/LzhB+ROt/DHy5piqxPeO6KWbFew4dUsNmJTxs7XRzEW BPhilDlZRFYkRUZHhT91CvP1kqUX2KjvW+m8yxs359qEklhymaa5TOzdvGzvSX+JkeW8 y5CRXhggQ6K5d9LAgrowIL3KOiI6ORyO3TYbiDHLgYzUhnEeYtff5aHkGz3QS4GBYvKc RLtQ==
X-Gm-Message-State: AKwxytcfvJLtvFPtQ6Ezmeg3vPffL29BBxyTz4SrerGtTdX4vQ10ol5Z YUf1NkCl0xPNM4CbDClx9+ty3WxM9D3iObUdVF/4+A==
X-Google-Smtp-Source: AH8x226PEiDNSgxzTgdKsW7rdC1T9dKG2dVU4fZrBwQZpFmO3xaBuW1g55SqZ60gXtqBkvMHpvleDcAG8LVKKrtbNrw=
X-Received: by 10.129.114.133 with SMTP id n127mr6416396ywc.296.1516827804784; Wed, 24 Jan 2018 13:03:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.160.201 with HTTP; Wed, 24 Jan 2018 13:02:44 -0800 (PST)
In-Reply-To: <014b01d39545$770a4480$651ecd80$@ndzh.com>
References: <151629775024.3841.11679795774117326021.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E7AAFAF80F@NKGEML515-MBX.china.huawei.com> <CABcZeBOW=gHNfCkScZaz0Wg1b0YDDLQ3H0PuOggx18dYmXQ_CQ@mail.gmail.com> <014b01d39545$770a4480$651ecd80$@ndzh.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 24 Jan 2018 13:02:44 -0800
Message-ID: <CABcZeBNmT+eTb3URva-9pmM5rboB0MdyWbNSUxVeprYCm1B-jA@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Cc: "Zhangmingui (Martin)" <zhangmingui@huawei.com>, The IESG <iesg@ietf.org>, trill-chairs@ietf.org, draft-ietf-trill-p2mp-bfd@ietf.org, trill@ietf.org
Content-Type: multipart/alternative; boundary="001a1149273a7d727505638bfefe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/ug3qmKQF4QTM_gDwOwDmVrqa-Vs>
Subject: Re: [trill] Eric Rescorla's No Objection on draft-ietf-trill-p2mp-bfd-08: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2018 21:03:31 -0000

Hi Susan,

Thanks for your note. I have not reviewed this document other than to see
that it seems to contain some sort of cryptographic authentication, and so
it would make sense for the draft under consideration now to rely on it.
What you say above sounds sensible I am unfortunately tied up this week at
the QUIC interim and therefore will not be able to take a closer look this
week. I could do so next week. Sorry about the inconvenience.

-Ekr


On Wed, Jan 24, 2018 at 10:59 AM, Susan Hares <shares@ndzh.com> wrote:

> Eric:
>
>
>
> Is there something I missed here.  The referenced document is RFC5880
> section 6.7 starts out:
>
> *6.7* <https://tools.ietf.org/html/rfc5880#section-6.7>*.  Authentication*
>
>
>
>    An optional Authentication Section MAY be present in the BFD Control
>
>    packet.  In its generic form, the purpose of the Authentication
>
>    Section is to carry all necessary information, based on the
>
>    authentication type in use, to allow the receiving system to
>
>    determine the validity of the received packet.  The exact mechanism
>
>    depends on the authentication type in use, but in general the
>
>    transmitting system will put information in the Authentication
>
>    transmitting system will put information in the Authentication
>
>
>
>    Section that vouches for the packet's validity, and the receiving
>
>    system will examine the Authentication Section and either accept the
>
>    packet for further processing or discard it.
>
>
>
> The section 6.7 describes four types of authentication: simple password [6.7.2] , Keyed MD5 and Meticulous Keyed MD5 [6.7.3], Keyed SHA and Meticulous Key SHA1 authentication [6.7.4].
>
>
>
> *Do you wish TRILL to recommend a particular authentication for this draft if they use the BFD authentication? *
>
>
>
> Please note that Kathleen noted this problem based on the sec-dir-review:
>
> https://mailarchive.ietf.org/arch/msg/secdir/KAZevWuVQAiukpRBKgjm7YIATRg
>
>
>
> Donald Eastlake’s response to the sec-dir review, and the changes in -08.txt are related to this issue.
>
>
>
> Donald points out that the RFC7978 provide strong authentication, and that we have a group keying mechanism ready for WG LC.  If you have  a moment, perhaps you can look at the group keying draft as well:
>
>
>
> https://datatracker.ietf.org/doc/draft-ietf-trill-group-keying/
>
>
>
> It would be helpful to me as a WG chair to know if we have missed anything before we go into WG LC with this document in 2 days. Donald will be glad to answer additional questions on the group keying draft.
>
>
>
> Cheerily, Susan Hares
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Wednesday, January 24, 2018 1:40 PM
> *To:* Zhangmingui (Martin)
> *Cc:* The IESG; trill-chairs@ietf.org; draft-ietf-trill-p2mp-bfd@ietf.org;
> shares@ndzh.com; trill@ietf.org
> *Subject:* Re: Eric Rescorla's No Objection on
> draft-ietf-trill-p2mp-bfd-08: (with COMMENT)
>
>
>
> OK. This doesn't seem like it blocks this document, but I'll have to take
> a closer look when the referenced document comes up.
>
>
>
> On Mon, Jan 22, 2018 at 1:40 AM, Zhangmingui (Martin) <
> zhangmingui@huawei.com> wrote:
>
> Hi Eric,
>
> Thanks for your review. When the referred document mentions Section 6.7,
> it actually points to the Section 6.7 of RFC5880.
>
> Thanks,
> Mingui
>
>
> > -----Original Message-----
> > From: Eric Rescorla [mailto:ekr@rtfm.com]
> > Sent: Friday, January 19, 2018 1:49 AM
> > To: The IESG
> > Cc: draft-ietf-trill-p2mp-bfd@ietf.org; Susan Hares;
> trill-chairs@ietf.org;
> > shares@ndzh.com; trill@ietf.org
> > Subject: Eric Rescorla's No Objection on draft-ietf-trill-p2mp-bfd-08:
> (with
> > COMMENT)
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-trill-p2mp-bfd-08: No Objection
> >
> > 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/statement/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-trill-p2mp-bfd/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I'm hoping this can be resolved quickly, as it's probably just a missing
> cite. If it
> > turns out that there's actually missing content, this may turn into a
> DISCUSS.
> >
> >    Multipoint BFD provides its own authentication but does not provide
> >    encryption (see Security Considerations in [I-D.ietf-bfd-
> >    multipoint]). As specified in this document, the point-to-multipoint
> >
> > I skimmed the reference here, but wasn't able to figure out what the
> > authentication was. In particular, the document says:
> >
> >       If the A bit is set, the packet MUST be authenticated under the
> >       rules of section 6.7, based on the authentication type in use
> >       (bfd.AuthType.)  This may cause the packet to be discarded.
> >
> > But there is no 6.7. So, this makes me worry that I don't understand any
> of this.
> >
>
>
>