Re: WGLC for BFD Multipoint documents (last round)

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Wed, 31 January 2018 14:47 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566F1131B97 for <rtg-bfd@ietfa.amsl.com>; Wed, 31 Jan 2018 06:47:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uNknHIFCMbqJ for <rtg-bfd@ietfa.amsl.com>; Wed, 31 Jan 2018 06:47:48 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B6B1317E1 for <rtg-bfd@ietf.org>; Wed, 31 Jan 2018 06:44:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7744; q=dns/txt; s=iport; t=1517409877; x=1518619477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0wpKtjMrT1llhvmSU1XSBrjMLqR9qqoeqwGRzrSEGcQ=; b=PNZa5ct9khaL3e+FVz1GZW9qmnT7UtPZirtwx3FRlyeljMuIYs+ZK9Uf nSCeEVdVbr9SCUrNNLoRi5oLWco6Im19Dyx3szCFpWKrME4ZSnj7MOnNL f11KABInFgP5C/keMoKugNbDJCgPouduwyHib6nYtMY+XCSli/DATC0aj o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CqAAA41XFa/5BdJa1QChkBAQEBAQEBAQEBAQEHAQEBAQGDQmZ1KAqDVookjiyCAokSjjSCFwojhRgCGoI1VBgBAQEBAQEBAQJrKIUjAQEBBCMRRRACAQYCEQMBAgECAiYCAgIfERUICAIEDgWKHQMVEIhcnXGCJ4c5DYMdAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4NMghWBV4FoKYMFgmtEAQECAQEXgSsrF4MAMYIUIAEEo2A+AogWiE6FBoIdkhCLBoJhR4kOAhEZAYE7AR85gVBwFRlOAYF/glUcggUBeIsdAYEWAQEB
X-IronPort-AV: E=Sophos;i="5.46,440,1511827200"; d="scan'208";a="64338893"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jan 2018 14:44:36 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w0VEiajX027475 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Jan 2018 14:44:36 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 31 Jan 2018 08:44:35 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1320.000; Wed, 31 Jan 2018 08:44:36 -0600
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WGLC for BFD Multipoint documents (last round)
Thread-Topic: WGLC for BFD Multipoint documents (last round)
Thread-Index: AQHTdDbMQKkp4UZhy0e3Kn8Lrj3T1qNFVBAAgABtnICAASUEgIADdUKAgADmoICAAGfFAIABPX0AgCk9u4CAAASiAIAAK1EAgAAqqgCAACNngIAABGqAgACB1oCAAEjuAIAAB2UAgAAsZQCAAA7FAIAAO8sAgAALOICAAA9fAIAMOY6AgAGCuACAASTJgIAAntGAgAGyGYCAACIhAIACLSSAgABGTICAABzRgIACEeYAgAC+OoA=
Date: Wed, 31 Jan 2018 14:44:35 +0000
Message-ID: <B5EA7CAD-36D4-470F-9A8D-4C5FE58E4C29@cisco.com>
References: <20171213172443.GC8708@pfrc.org> <CA+RyBmX6PHczvwEzc4UNqBioK8qv=wTfyeHg9j04EJNe1Uv0wA@mail.gmail.com> <746F74E2-7DFC-41A7-879F-4054CF95475C@cisco.com> <CA+RyBmWqGPTkBek+a0N+BaFr9QZ+xEKvWT5oRxPBuhFsQcizcw@mail.gmail.com> <38B53F72-66B9-4E8F-8BCE-C28A2C283D38@cisco.com> <20171219160537.GH8708@pfrc.org> <CA+RyBmWQTH9N9cCOHJ_9BgvfDGLGFgrsKrMj8mmqGm-V=5KLSw@mail.gmail.com> <20171220171322.GE8708@pfrc.org> <7C073038-8E7D-4735-82A4-97592AA9B34B@cisco.com> <CA+RyBmXanVpKKmyXP9+yuh4z2H4qAeN4jH2xEMx7ddiSHViV3g@mail.gmail.com> <DB3B0F10-4BD8-4096-8875-2E476064E77A@cisco.com> <491F0297-F2AB-4377-A013-1050FDBBB709@cisco.com> <CA+RyBmVXO0o09k-DYY69E2sKdKiU5YBf-h=PnBgerx+HF=ryfg@mail.gmail.com> <44B4B608-7A2B-4E95-A5F7-116896C57028@cisco.com> <0714A770-BF3F-4EF8-A302-A478439A5B13@cisco.com> <5F69E3D1-19E1-45F7-926D-61449E1F09B2@cisco.com> <CA+RyBmWMwom+2=jWHfvSr9AG=WPCnhYJ6uC9HVonVFh9McaysQ@mail.gmail.com> <E14FF8C0-082B-4D52-89F6-0CBAF9CD4181@cisco.com> <CA+RyBmUOpBgVho0SPsp9FB=ymFV29q_2EY2k8uOf-O4gfpTmyw@mail.gmail.com> <CA+RyBmXs_gRjeUk9gx0653WkvjDfztD-cgNw=mNX+66Whj_AFw@mail.gmail.com> <639B40D7-F79B-4546-93B3-55812C880217@cisco.com> <CA+RyBmUEG2L4ExWRCvLYVMs=BL5OsGRpfD0a9RLEvu+4Avhy9A@mail.gmail.com> <E816D829-7F6D-478A-9DE6-F5C5A177B981@cisco.com> <CA+RyBmUeJi5Rttr+5PiNUBEo1cr10pvcg=twC3Biz+c6xT7iGQ@mail.gmail.com> <28FBFF19-27FD-41DB-A0CF-29DC3CED119A@cisco.com> <CA+RyBmVh_uKZ8rT+03YhhF4W6qiDBRmeK9BtbUEo_ZuTdzkfBw@mail.gmail.com> <A44E5437-C394-4110-9FFC-99EA06D8186D@cisco.com> <CA+RyBmVNU6bt2KVw+=xsFU0J3fmoBNX9QP8GF+eCbPzbyWTSjg@mail.gmail.com> <7F1C8A95-18DE-42D0-9DF5-A6920ED4029F@cisco.com> <CA+RyBmXyT4UbfP_y7KuuoABp1TQ5db2x_R-4az-bGP=7d2ssGQ@mail.gmail.com> <F9C80743-5159-4D5E-9B33-54E0F2160FC6@cisco.com> <CA+RyBmWHyG8TRA2DbSd+mK6wK8Odc+sERAguj7tG6sCJQcyrTg@mail.gmail.com>
In-Reply-To: <CA+RyBmWHyG8TRA2DbSd+mK6wK8Odc+sERAguj7tG6sCJQcyrTg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.65]
Content-Type: text/plain; charset="utf-8"
Content-ID: <71082B38BD20714A8DA130E06D71FF62@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/u-I4_-ZoKpDE3780UZjIXntJMjE>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jan 2018 14:47:51 -0000

Hi Greg,

Thanks for addressing the changes so promptly. I’d like to hear from the WG on the 2 security concerns below, i.e. whether they need to be addressed and if yes, then how. I believe if we address a) below we also address b)?

Regards,
Reshad.

: a) We should have the ability, e.g. via configuration, to prevent the number
: of MultipointTail sessions from exceeding the number of expected streams.
: Otherwise 1 misbehaving head could use up all the MultipointTail session
: resources on a tail.
: b) A misbehaving head which changes My Discriminator for a MultipointHead
: session will cause tails to create many MultipointTail sessions (4.13.2). We
: should consider adding a check to see if we have a MultipointTail session
: based on source address and the identify of the of the multipoint tree with a
: different discriminator?

7.  Security Considerations

   The same security considerations as those described in [RFC5880]
   apply to this document.  Additionally, implementations that create
   MultpointTail sessions dynamically upon receipt of Multipoint BFD
   Control packets MUST implement protective measures to prevent
   infinite number of MultipointTail sessions being created.  Below are
   listed some points to be considered in such implementations.

      If a Multipoint BFD Control packet did not arrive on a multicast
      tree (e.g. on expected interface, with expected MPLS label, etc),
      then a MultipointTail session should not be created.

      If redundant streams are expected for a given multicast stream,
      then the implementations should not create more MultipointTail
      sessions than the number of streams.  Additionally, when the
      number of MultipointTail sessions exceeds the number of expected
      streams, then the implementation should generate an alarm to users
      to indicate the anomaly.



Katz, et al.             Expires August 3, 2018                [Page 16]


Internet-Draft         BFD for Multipoint Networks          January 2018


      The implementation should have a reasonable upper bound on the
      number of MultipointTail sessions that can be created, with the
      upper bound potentially being computed based on the number of
      multicast streams that the system is expecting.

On 2018-01-30, 10:23 PM, "Greg Mirsky" <gregimirsky@gmail.com> wrote:

    Hi Reshad, et.al,
    I've uploaded the new version of the draft:
    
    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the Bidirectional Forwarding Detection WG
    of the IETF.
    
            Title           : BFD for Multipoint Networks
            Authors         : Dave Katz
                              Dave Ward
                              Santosh Pallagatti
                              Greg Mirsky
            Filename        : draft-ietf-bfd-multipoint-13.txt
            Pages           : 18
            Date            : 2018-01-30
    
    Abstract:
       This document describes extensions to the Bidirectional Forwarding
       Detection (BFD) protocol for its use in multipoint and multicast
       networks.
    
    
    
    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
    
    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-bfd-multipoint-13
    https://datatracker.ietf.org/doc/html/draft-ietf-bfd-multipoint-13
    
    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-13
    
    Will respond to your comments on the Active Tails shortly.
    
    Regards,
    Greg
    
    
    On Mon, Jan 29, 2018 at 11:47 AM, Reshad Rahman (rrahman)
    <rrahman@cisco.com> wrote:
    > Greg, these changes are good with me.
    >
    >
    >
    > Regards,
    >
    > Reshad.
    >
    >
    >
    > From: Greg Mirsky <gregimirsky@gmail.com>
    > Date: Monday, January 29, 2018 at 1:04 PM
    > To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
    > Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Jeffrey Haas
    > <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
    > Subject: Re: WGLC for BFD Multipoint documents (last round)
    >
    >
    >
    > Hi Reshad,
    >
    > nits fixed and the new text below:
    >
    > OLD TEXT
    >
    > A number of values of the state variable are added to the base BFD…
    >
    > NEW TEXT
    >
    > A number of new values of the state variable bfd.SessionType are added to
    > the base BFD…
    >
    > Would you accept this update?
    >
    >
    >
    > Regards,
    >
    > Greg
    >
    >
    >
    > On Mon, Jan 29, 2018 at 5:52 AM, Reshad Rahman (rrahman) <rrahman@cisco.com>
    > wrote:
    >
    > Hi Greg,
    >
    >
    >
    > Section 4.2. s/The head has a session of type MultipointHead Section 4.4.1/
    > The head has a session of type MultipointHead, as defined in Section 4.4.1,
    > /
    > Section 4.4.1. “A number of values of the state variable are added to the
    > base BFD…”. That sentence needs rewording IMO but maybe I’m just missing
    > what it’s trying to convey.
    > Section 4.6. s/Active role , / Active role, /
    > Section 4.10. “MUST send packets with P bit set.”. Did we agree on “MUST
    > send packets with the P bit set.”?
    >
    >
    >
    > Regards,
    >
    > Reshad.
    >
    >
    >
    > <snip>
    >
    >