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

Jeffrey Haas <jhaas@pfrc.org> Thu, 19 December 2019 18:01 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 98F4D1209AA; Thu, 19 Dec 2019 10:01:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 IwI-zU6fMyAD; Thu, 19 Dec 2019 10:01:47 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D19A81208FE; Thu, 19 Dec 2019 10:01:39 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 8DED61E2F6; Thu, 19 Dec 2019 13:06:10 -0500 (EST)
Date: Thu, 19 Dec 2019 13:06:10 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
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: Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)
Message-ID: <20191219180609.GA27686@pfrc.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B88794A5-553E-453D-8CAF-1D05FCA56C1E@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/vVN9v8otCHih0a25izXL7LmOsH4>
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 18:01:50 -0000

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>のメール:
> > 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.

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?

> > 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.  

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:

- 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.

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.

-- Jeff