Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Thu, 19 December 2019 20:13 UTC

Return-Path: <cpignata@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 40E91120B93; Thu, 19 Dec 2019 12:13:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, SPF_PASS=-0.001, 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 header.b=XweYyXiv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hmQGmpQv
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 twkMyOhvu-zt; Thu, 19 Dec 2019 12:13:00 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4935F120A96; Thu, 19 Dec 2019 12:13:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6098; q=dns/txt; s=iport; t=1576786380; x=1577995980; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xW85fga+bJs0RZrwpUp1r2iqo+egc4zRXAdao7iaTkg=; b=XweYyXivAvj8pBFiKbGp8mkWIDqTgqoPhpYNW8ECtgC436YffejoRD0y Xfu6v9b8C2Hkh0CyQPUUeb1+lizTZwnc+CZRh3U8mn83xfSRREG39NlMm 0d9JToTGZJs0wf8g05/IVB/kjgDv3Yk4cbz+PBolszSegeXupmWtAuZPe s=;
IronPort-PHdr: =?us-ascii?q?9a23=3AOES9hhJnPGBB5m3VFdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEbjLfHsZjAzNM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcBQB22ftd/4gNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBTVAFbFggBAsqCoN8g0YDinOCX4EBlweCUgNUCQEBAQwBASU?= =?us-ascii?q?IAgEBhEACF4IFJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECARIREQwBATc?= =?us-ascii?q?BBAsCAQYCDgoCAiYCAgIwFQULAgQOBRsHgwABgkYDDiABDgORI5BkAoE4iGF?= =?us-ascii?q?1gTKCfgEBBYE1AYNvGIIMAwaBDiiJUIJJGoFBP4ERJyCCFzU+gmQCgWIBgxA?= =?us-ascii?q?ygiyPfjmdZHQKgjSHMo5mG5pRg0eTXI5YgycCBAIEBQIOAQEFgWkigVhwFTs?= =?us-ascii?q?qAYJBPhIYDY0SDBcVgzuFFIU/dIEojlwBgQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.69,333,1571702400"; d="scan'208";a="386318340"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Dec 2019 20:12:59 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xBJKCxST017489 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Dec 2019 20:12:59 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 14:12:58 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Dec 2019 15:12:57 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 19 Dec 2019 14:12:57 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MqCy1nrbHNCWprk0YVN/UIg3ZWdMuPKQcJ4d4OOcy0ppN8T8+dyN3nvCG7ThF2b2bby36s767mCJcYGxubpEAwudGOekVddsOKOLtPbRmDYc0cCfifVxkWCz6xdfiienhLolFN0Q83gNg9vWSpf2IGj7UwmD/pD5pwTzw3kZcMVM5B/zu7krx+NGM9IRrk4CJ2w1UeuBFO4a7DwfQw9wLeiJ2x7mQcw16Z2ZGs2JbIz7HCJdbEULCscOxq2RTFRKruvvy0+JdFWJYRIvhJG6rwF/udG7bc2iltxaMKMrONGb3vigUVuwrQZcR7oJgVFh8erqIUHCE0EsKYq7YkgJqg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xW85fga+bJs0RZrwpUp1r2iqo+egc4zRXAdao7iaTkg=; b=UVJmVErzAkmQ4ZZfjoR/yUV+rcHpBs5JXIMv003MAL1RxnMcYw0/YyWP8VhovYBRxVngqsFe61TMKVRlMWcyQoi8dkAviKYr8kihdJnKtK5MXJk/p3CFQcW07W4OnZ8f7obSg6icLtJ4nY0j+znaU/IhgBmf0pGEz0E1SXcGO+awDfc7vl37y1Ien7z9vkZrjjxBp4G8AbBPINNO9+UsyqFwyp0TBzZUNA3WPb3ctfO/CdpYLMe0Grmzlv9UmOccNnLj/Nh72YtC3dteQ99Y9unfoA7AFfSu+Zjm9FBx4KVTjJ8WfUXYW6gpkXDj9vkB/3+Hljf+NMn8YtnFdJdyZw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xW85fga+bJs0RZrwpUp1r2iqo+egc4zRXAdao7iaTkg=; b=hmQGmpQvidJnOaUu87fmCg5EtQYlR2watG6zMv7/Gopx0v4V/VFPB2wrSYnkuDNOAtgYKT13nTfyfOxpxCNwCjLRHJXGczp4HSv/xX0tM6r2curfNYp7KsAamTFGOBn48ahsHfTujv5v6xBafEFJCeTQacGgyq9gRk/gda7NZ5E=
Received: from BN6PR11MB0034.namprd11.prod.outlook.com (10.161.156.160) by BN6PR11MB3971.namprd11.prod.outlook.com (10.255.129.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2559.13; Thu, 19 Dec 2019 20:12:56 +0000
Received: from BN6PR11MB0034.namprd11.prod.outlook.com ([fe80::d4cf:20e6:8706:d006]) by BN6PR11MB0034.namprd11.prod.outlook.com ([fe80::d4cf:20e6:8706:d006%5]) with mapi id 15.20.2538.019; Thu, 19 Dec 2019 20:12:56 +0000
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Jeff Haas <jhaas@pfrc.org>
CC: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "draft-ietf-bfd-vxlan@ietf.org" <draft-ietf-bfd-vxlan@ietf.org>, The IESG <iesg@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
Subject: =?utf-8?B?UmU6IMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1iZmQt?= =?utf-8?Q?vxlan-09:_(with_DISCUSS_and_COMMENT)?=
Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWJmZC12eGxh?= =?utf-8?Q?n-09:_(with_DISCUSS_and_COMMENT)?=
Thread-Index: AQHVtLc75ryADAJO5Ui6+24NC5naA6e+kjMAgAHIsoD//7wKAIAAV1IAgABfYYCAAPbrAIAAI2qA
Date: Thu, 19 Dec 2019 20:12:56 +0000
Message-ID: <4744CBE3-E9EC-439D-B699-C301CFF200D3@cisco.com>
References: <157657269782.26511.12421406428553874826.idtracker@ietfa.amsl.com> <CED2B858-AC55-4B0A-ADA2-AC46B628E6DA@cisco.com> <20191218203145.GD6488@pfrc.org> <FE5AEE55-9F03-49E9-89C3-6C9700C8683E@cisco.com> <20191218214102.GF6488@pfrc.org> <B88794A5-553E-453D-8CAF-1D05FCA56C1E@cisco.com> <20191219180609.GA27686@pfrc.org>
In-Reply-To: <20191219180609.GA27686@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.40.2.2.4)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com;
x-originating-ip: [173.38.117.67]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b5f4e28d-3392-4ad1-aa5a-08d784bfd645
x-ms-traffictypediagnostic: BN6PR11MB3971:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN6PR11MB3971419EF3C2169245B31187C7520@BN6PR11MB3971.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(376002)(346002)(366004)(136003)(199004)(189003)(6916009)(26005)(224303003)(6512007)(966005)(478600001)(2616005)(6506007)(71200400001)(33656002)(316002)(6486002)(8936002)(81156014)(54906003)(4326008)(81166006)(86362001)(186003)(2906002)(5660300002)(64756008)(66476007)(66446008)(66946007)(91956017)(66556008)(36756003)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB3971; H:BN6PR11MB0034.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: JZ+MtjBSOOiuVT8NyhjFGRhRppnnv6saNe5s6+z2xe1q+vYS7xzkypamocvM+rkIdSq/GTvobU730Qq1OyVp3aR7ejNRvqZg2fVLX2fjZlE/ZSt0g8ZkWIPlN4rNwThsu9sXodCVsY0H1QJXZd4rqtjicoJEsNMNAbTty2Qsx1lik5iikc6/2Qm+dSIgnShd9LX8LquysVEkEHcW55tf9SBju94kDZCMYJ9Hai/LmAVpH0evsKSIO64PapiJjTfs9PiVunb97Gh6NG5AG5+KNDaRLgR90HQnpLoWdxztTKxYw28bZwjLMSLNoaxOxgtpU5BF4DLN404Q2mpsS0wv0Ktkwho2c82AFWLEDjCbvtUijb8DZZi6NauNOdZYqL6RIYWohPTI4oiWlBQgWra8yrOHPceoOH3nHY3RxbIf34PB+FoD7kOhvpA1zHX35UtFUr0GPVY23CvAs/kI2WHMQCvfoe1CjuGDaMlkx3QSekY=
Content-Type: text/plain; charset="utf-8"
Content-ID: <794DFDDAC812F14680490BEAC941745D@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b5f4e28d-3392-4ad1-aa5a-08d784bfd645
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2019 20:12:56.3514 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +vd0JeDDkVSJJmgZEV/Uqxb33jr9CRh5QIlKPbi1tkHTSbqDeVlc7rbfV1QNhDgCGZdbAEtOeQWN6Pn6JunfTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3971
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/xc19mlgpdnvw7zhZlwD92tBxWZE>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 19 Dec 2019 20:13:02 -0000

Hi, Jeff,

> 2019/12/19 午後1:06、Jeffrey Haas <jhaas@pfrc.org>のメールt;のメール:
> 
> Carlos,
> 
> On Thu, Dec 19, 2019 at 03:22:28AM +0000, Carlos Pignataro (cpignata) wrote:
>>> 2019/12/18 午後4:41、Jeffrey Haas <jhaas@pfrc.org>のメールt;のメール:
>>> But given that point, what precisely is the objection to the inner IP header
>>> of the BFD for vxlan having a TTL of 1?
>> 
>> The intent would be to protect of potential attacks beyond the encapsulating endpoint (i.e., packet coming into the VTEP vs. sourced, off-link spoofing).
> 
> I'm sorry if I'm seeing oblivious, but I'm missing something.
> 

No need to be sorry — useful dialogue! Thank you!

> The encapsulated packet's outer IP header, if single hop, could certainly
> benefit from GTSM procedures.
> 
> But once you're more than one hop away, and you're vulnerable to general
> attacks against packet insertion that the base vxlan PDUs have, how exactly
> does setting the TTL one way or the other provide protection?

Think of the VXLAN tunnel as a sigle-hop link. Yes, midpoint/in-transit packet insertion is an attack vector not covered by GTSM-ing the inner IP. However, traffic from outside the VXLAN (i.e., from outside the infrastructure) routed into the tunnel could not have a 255 TTL/HL.

> 
>>> I think this is partially a matter of attack spaces varying depending on
>>> whether we're targeting the management VNI vs. a tenant.  In the case of the
>>> management VNI, we (should) have very strong control over what BFD traffic
>>> is getting encapsulated.  
>>> 
>>> However, for tenant VNI mode, is the argument that depending on what the
>>> other vxlan PDU parameters look like, tenant sourced BFD PDUs may be
>>> indistinguishable from ones sourced by the management infrastructure?  And
>>> if so, how would GTSM help us here?
>> 
>> Tenant sourced BFD PDUs would not use host loopback dest addresses. Scanning through S6 of draft-ietf-bfd-vxlan-09, "MAY support the use of the Management VNI”.
>> 
>> And if there are already protections for not over-forwarding the BFD pak, the flip-question is “what does TTL = 1 bug you?”
>> 
>> My assumption was that if the base BFD specs say “GSTM is useful”, why not here?
> 
> Personally, I'm mostly ambivalent if it helps.  
> 

I am also not fixated in any solution. 

However, I am not ambivalent about comments being simply ignored. I would like the Editors and pen-holders of this document to actually respond to comments.

I am not looking for a specific answer, but I am looking for a thoughtful, deliberate, explicit, and intentional decision, shared on the list. That’s the role of Editors.

For example, see comment #2 in this note from June 2019 https://mailarchive.ietf.org/arch/msg/rtg-bfd/BL9Ob66Yxie4wX13yZJELbYPLJs 

That comment, as well as others on that same note, were not ever responded to or acknowledged.

I reminded the editor that some comments were not being answered to: https://mailarchive.ietf.org/arch/msg/rtg-bfd/uzAtld-P7qB3B5z3NViFx83oaGA

Still, that thread did not even attempt to answer my question #2.

> If my observation above above about insertion attacks is valid, then using
> GTSM for the inner IP packet isn't helpful for protecting against what GTSM
> is intended for.  This leave us with roughly two modes:

Yes, it is valid, but it is not the only attack vector.

> 
> - With GTSM, enforce the usual related BFD procedure.  If packets aren't
>  "caught" by BFD, they have the potential to bounce around until they
>  expire.  Either way, BFD should go Down and the max damage is a number of
>  BFD packets eventually settling back to the 1/sec timer.
> - Without GTSM, exactly the same, just with less distance.
> 
> So, presuming my observation is valid:
> It doesn't help.
> It doesn't hurt (much).
> If we want to require it, go for it.
> 

I have the same question as before though.

To me the real vector of questions is: If the base GTSM spec requires it, why is that requirement relaxed? Where is it explained in the document?

> But it doesn't help your security story at all and using it perhaps confuses
> people about it actually helping.  So, don't insist on it for security
> reasons.

I would say “don’t insist on it for every possible security reason”. The fact that there are some cases not covered does not imply that there are none.



> 
> -- Jeff