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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 17 Dec 2019 00:51:37 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-bfd-vxlan-09: 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/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-bfd-vxlan/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document.

I fully second Adam's COMMENT that should be fixed before publication (IMHO
this is a DISCUSS).

Answers to my COMMENTs below will be welcome, even if those COMMENTs are not
blocking.

As usual, an answer to the DISCUSS is required to clear my DISCUSS though.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

May be I am not familiar enough with BFD, but, RFC 5881 (the one defining BFD)
specifies the use of TTL = Hop Limit = 255.. Why this document uses a value of
1 ?

-- Section 3 --
IPv4-mapped IPv6 addresses are only to be used inside a host and should never
be transmitted in real packets (including packets inside a tunnel) see section
4.2 of RFC 4038 (even if informational). As other IESG reviewers, I wonder why
::1/128 is not used?

-- Section 8 --
The document specifies no IANA actions while the shepherd write-up talks about
a IANA action.

-- Section 9 --
This section is only about IPv4 (TTL and RFC 1812). Please address IPv6 as well.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== COMMENTS ==

RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that
this document is only required to address the Ethernet encapsulation ? I.e.
specifying the Ethernet MAC addresses?

-- Section 3 --
At first sight, I was surprized by having a BFD session per VXLAN VNI as it
will create some scalability issue, but, I assume that this is to detect
misconfiguration as well. If so, perhaps worth mentionnig the reasoning behind?

In "the inner destination IP address SHOULD" it is unclear whether it is in the
all BFD packets, or only the request one or ... ?

-- Section 4 --
While probably defined in RFC7348, should "FCS" be renamed as "Outer Ethernet
FCS" for consistency with the "Outer Ethernet Header" in figure 2 ?

Why not using the Source MAC address as the Destination MAC address ? This
would ensure that there is no conflict at the expense of "forcing" the
transmission of the frame even if addressed to itself.

Please consider rewriting the section about TTL/Hop Limit as it is not easy to
parse/read.

-- Section 9 --
It is unclear to me (see also Ben's comment) what is the 'attack vector' of
sending packets with TTL=1 ?

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 17 Dec 2019 17:17:11 +0000

Hi, Éric,

Regarding you first DISCUSS element, I had brought up the same issue. See the 2nd point at https://mailarchive.ietf.org/arch/msg/rtg-bfd/BL9Ob66Yxie4wX13yZJELbYPLJs

Thanks,

Carlos.

2019/12/17 午前3:51、Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>>のメール:

Regards,

-éric

== DISCUSS ==

-- Section 3 --

-- Section 8 --

-- Section 9 --

== COMMENTS ==

-- Section 3 --

-- Section 4 --

-- Section 9 --

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 18 Dec 2019 15:31:45 -0500

Carlos, Éric,

Note that I'm not an expert in the underlying MPLS technologies.  I'll make
two notes:

BFD for vxlan is in a similar feature-space as RFC 5884, BFD for MPLS.

RFC 5884, section 7, paragraph 3, suggests a TTL of 1 and provides a
reference to RFC 4379.

RFC 4379, section 4.3, provides procedures for TTL of 1.

My personal inference would be that implementations at least in MPLS-land
really want the TTL to be 1 for purposes of doing appropriate encapsulation
checks. 

I agree that GTSM procedures would suggest we may want TTL of 255.

I suggest the answer we're looking for here would be provided by parties
with appropriate history on why RFC 4379 recommends its procedures.  

Failing that, I suspect BFD for vxlan is no worse than 4379.

-- Jeff

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 18 Dec 2019 21:28:30 +0000

Hi, Jeff,

The TTL of 1 recommended for RFC 4379 / RFC 8029 S4.3 is because if the MPLS packet is mis-routed, or there's a forwarding mis-programming, then an MPLS LSE pop would expose the BFD packet and so that the BFD is not further mis-forwarded.

In the VXLAN case an intermediate router would not remove the VXLAN encap because the outer encap is IP (with a destination address, not an MPLS Label that can be mis-interpreted in context) and a mid-point router would not understand VXLAN.

Thanks,

Carlos.

2019/12/18 午後3:27 に、"Jeffrey Haas" <[email-masked]> を書き込みました:

    Carlos, Éric,

    

    

    
    -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 18 Dec 2019 16:41:02 -0500

Carlos,

> In the VXLAN case an intermediate router would not remove the VXLAN encap because the outer encap is IP (with a destination address, not an MPLS Label that can be mis-interpreted in context) and a…

Explained, that now seems obvious.  Thanks. :-)

But given that point, what precisely is the objection to the inner IP header
of the BFD for vxlan having a TTL of 1?

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?

-- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Dec 2019 18:19:45 -0800

Hi Carlos, Jeff, et al.,
thank you for a very insightful discussion.
Based on the input from the experts familiar with VXLAN deployment scenario
the following text was added to justify the requirement to set TTL or Hop
Limit to 1:
         TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
         packet is not routed within the Layer 3 underlay network.  This
         addresses the scenario when the inner IP destination address is
         of VXLAN gateway and there is a router in underlay which
         removes the VXLAN header, then it is possible to route the
         packet as VXLAN  gateway address is routable address.

Best regards,
Greg

On Wed, Dec 18, 2019 at 1:36 PM Jeffrey Haas <[email-masked]> wrote:

> > The TTL of 1 recommended for RFC 4379 / RFC 8029 S4.3 is because if the
> MPLS packet is mis-routed, or there's a forwarding mis-programming, then an
> MPLS LSE pop would expose the BFD packet and so that the BFD is not further
> mis-forwarded.
> >
> > In the VXLAN case an intermediate router would not remove the VXLAN
> encap because the outer encap is IP (with a destination address, not an
> MPLS Label that can be mis-interpreted in context) and a mid-point router
> would not understand VXLAN.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 19 Dec 2019 03:22:28 +0000

Hi, Jeff,

> 2019/12/18 午後4:41、Jeffrey Haas <[email-masked]>のメール:
> 
> Carlos,
> 

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

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

Thanks,

Carlos.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 18 Dec 2019 18:09:53 -0800

Hi Eric,
thank you for your review, comments, and suggestions. Please find my
answers below under GIM>> tag. Also, attached is the diff to the working
version of the document that includes updates that Adam has suggested.

Best regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/
GIM>> I've applied changes suggested by Adam to the working version of the
document.

> specifies the use of TTL = Hop Limit = 255.. Why this document uses a
GIM>> Jeff and Carlos are in a very detailed and insightful discussion.
I'll wait for its conclusion and follow on their agreement.

> 4.2 of RFC 4038 (even if informational). As other IESG reviewers, I wonder
GIM>> The mechanism of using an address from the loopback address range or
IPv4-mapped addresses of that range may be used to create entropy and
monitor ECMP paths in an IP/MPLS network (RFC 8029 and RFC 5884). This
specification uses the same mechanism for ECMP environment in the underlay
network.

> The document specifies no IANA actions while the shepherd write-up talks
GIM>> RtgDir review from Joel Halpern and the extensive discussion on BFD
WG list lead to this change. As a result, the request to allocate a MAC
address to be used as the destination MAC address in the inner Ethernet
header was withdrawn and removed from the specification.

> This section is only about IPv4 (TTL and RFC 1812). Please address IPv6 as
GIM>> Added "or Hop Limit". Please let me know if you agree. As for a IPv6
relevant reference equivalent to RFC 1812, Adam Roach has noted that RFC
8504 does not have anything of the kind. At the same time, the use of
IPv4-mapped loopback address range has been mandated in RFC 8029 and RFC
5884.

GIM>> There were several threads on encapsulation of BFD Control packet
over VXLAN that, in my estimation, gathered 150+ messages. As you've
noticed from the Shepherd write-up, the use of the dedicated MAC address
was proposed, discussed, and documented. But later the WG decided not to
use the dedicated MAC as the destination MAC in the inner Ethernet frame.
Similarly, we had an extended discussion, including valuable input from
implementors of BFD over VXLAN, on the selection of the destination IP
address in the inner IP header. And another set of issues was discovered
related to the selection of VXLAN VNI value when encapsulating  BFD control
packet. I hope we've analyzed all encapsulation issues and documented them
sufficiently for the benefit of future implementations.

> misconfiguration as well. If so, perhaps worth mentionnig the reasoning
GIM>> I agree, detecting misconfiguration might be one of the reasons to
run BFD over some VXLAN VNIs. Would the following text be acceptable:

NEW TEXT:
   Using a BFD session to monitor a set of VXLAN VNIs between
   the same pair of VTEPs might help to detect and localize problems
   caused by misconfiguration.

> all BFD packets, or only the request one or ... ?
GIM>> This is applicable to all BFD control packets transmitted over a
VXLAN tunnel. To clarify, I propose the following change:
OLD TEXT:
As per Section 4, the inner destination IP address SHOULD be set to ...
NEW TEXT:
   For BFD Control packets encapsulated in VXLAN
   (Figure 2), the inner destination IP address SHOULD be set to ...

> FCS" for consistency with the "Outer Ethernet Header" in figure 2 ?
GIM>> Would s/FCS/Outer FCS/ be acceptable?

> transmission of the frame even if addressed to itself.
GIM>> Based on the input from experts familar with existing
implementations, WG decided not to require the use of the specific MAC
address. I think that using the Source MAC as the Destination might be one
of the options an implementation will use.

> Please consider rewriting the section about TTL/Hop Limit as it is not
GIM>> Could you help me kindly and point to the problematic text?

> sending packets with TTL=1 ?
GIM>> Another input from experts familiar with VXLAN and its deployments
reflected in the following:
          TTL or Hop Limit: MUST be set to 1 to ensure that the BFD
         packet is not routed within the Layer 3 underlay network.  This
         addresses the scenario when the inner IP destination address is
         of VXLAN gateway and there is a router in underlay which
         removes the VXLAN header, then it is possible to route the
         packet as VXLAN  gateway address is routable address.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 19 Dec 2019 12:48:43 +0000

Greg,

Thank you for the new text but I still believe that forwarding in the data plane a packet with TTL/HL=254 (assuming TTL/HL=255 at source) is less an issue than forcing the control plane of a VNI/gateway to reply to a remote BFD (the whole idea behind GTSM is to accept only local traffic). Moreover, a bad behaving routers is probably less probable than a bad behaving VM (although I am unsure about the threat model in this case).

Else, please s/ removes the VXLAN header/ removes the outer IP + UDP + VXLAN headers/

Also, note that IPv6 packets with HL=0 but with a matching dest addr will be accepted by IPv6 nodes.

-éric

From: Greg Mirsky <[email-masked]>
Date: Thursday, 19 December 2019 at 03:20
To: Jeffrey Haas <[email-masked]>
Cc: "Carlos Pignataro (cpignata)" <[email-masked]>, Eric Vyncke <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

Hi Carlos, Jeff, et al.,
Based on the input from the experts familiar with VXLAN deployment scenario the following text was added to justify the requirement to set TTL or Hop Limit to 1:

Best regards,
Greg

On Wed, Dec 18, 2019 at 1:36 PM Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Carlos,

-- Jeff

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 19 Dec 2019 14:09:47 +0000

Greg,

2nd reply as you replied in 2 messages ;-)

Please see in-line for EV>

But, for the most critical IMHO issue about using IPv4-mapped IPv6 addresses, I had a look at RFC 8029 and RFC 5884 and was, honestly, shocked by their use of IPv4-mapped addresses over the wire “just to add entropy”.

First, it is not because a mistake has been made in the past that repeating the same mistake is a good thing ;-)

Second, adding entropy could also be done with the IPv6 flow field.

Third, I wonder why adding entropy in the inner/overlay IP header would assist the ECMP in the underlay as I have doubt that underlay data plane will look so deep into the packets ... So, isn’t it useless in this case ?

Thank you again for the work and your reply

-éric

From: Greg Mirsky <[email-masked]>
Date: Thursday, 19 December 2019 at 03:17
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, Jeffrey Haas <[email-masked]>, "[email-masked]" <[email-masked]>, rtg-bfd WG <[email-masked]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

Hi Eric,
thank you for your review, comments, and suggestions. Please find my answers below under GIM>> tag. Also, attached is the diff to the working version of the document that includes updates that Adam has suggested.

Best regards,
Greg

On Tue, Dec 17, 2019 at 12:51 AM Éric Vyncke via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-bfd-vxlan-09: Discuss

I fully second Adam's COMMENT that should be fixed before publication (IMHO
this is a DISCUSS).
GIM>> I've applied changes suggested by Adam to the working version of the document.

Regards,

-éric

== DISCUSS ==

May be I am not familiar enough with BFD, but, RFC 5881 (the one defining BFD)
specifies the use of TTL = Hop Limit = 255.. Why this document uses a value of
1 ?
GIM>> Jeff and Carlos are in a very detailed and insightful discussion. I'll wait for its conclusion and follow on their agreement.

EV> see my previous email about this.

-- Section 3 --
IPv4-mapped IPv6 addresses are only to be used inside a host and should never
be transmitted in real packets (including packets inside a tunnel) see section
4.2 of RFC 4038 (even if informational). As other IESG reviewers, I wonder why
::1/128 is not used?
GIM>> The mechanism of using an address from the loopback address range or IPv4-mapped addresses of that range may be used to create entropy and monitor ECMP paths in an IP/MPLS network (RFC 8029 and RFC 5884). This specification uses the same mechanism for ECMP environment in the underlay network.

-- Section 8 --
The document specifies no IANA actions while the shepherd write-up talks about
a IANA action.
GIM>> RtgDir review from Joel Halpern and the extensive discussion on BFD WG list lead to this change. As a result, the request to allocate a MAC address to be used as the destination MAC address in the inner Ethernet header was withdrawn and removed from the specification.

EV> can the document shepherd update the shepherd write up ?

-- Section 9 --
This section is only about IPv4 (TTL and RFC 1812). Please address IPv6 as well.
GIM>> Added "or Hop Limit". Please let me know if you agree. As for a IPv6 relevant reference equivalent to RFC 1812, Adam Roach has noted that RFC 8504 does not have anything of the kind. At the same time, the use of IPv4-mapped loopback address range has been mandated in RFC 8029 and RFC 5884.

EV> OK, even if I do not like the unbalance

== COMMENTS ==

RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that
this document is only required to address the Ethernet encapsulation ? I.e.
specifying the Ethernet MAC addresses?
GIM>> There were several threads on encapsulation of BFD Control packet over VXLAN that, in my estimation, gathered 150+ messages. As you've noticed from the Shepherd write-up, the use of the dedicated MAC address was proposed, discussed, and documented. But later the WG decided not to use the dedicated MAC as the destination MAC in the inner Ethernet frame. Similarly, we had an extended discussion, including valuable input from implementors of BFD over VXLAN, on the selection of the destination IP address in the inner IP header. And another set of issues was discovered related to the selection of VXLAN VNI value when encapsulating  BFD control packet. I hope we've analyzed all encapsulation issues and documented them sufficiently for the benefit of future implementations.

EV> actually, I was not clear. I wonder why RFC 5881 (that claims to be applicable to IPv4/IPv6 tunnels) is not applicable to VXLAN.

-- Section 3 --
At first sight, I was surprized by having a BFD session per VXLAN VNI as it
will create some scalability issue, but, I assume that this is to detect
misconfiguration as well. If so, perhaps worth mentionnig the reasoning behind?
GIM>> I agree, detecting misconfiguration might be one of the reasons to run BFD over some VXLAN VNIs. Would the following text be acceptable:

NEW TEXT:

EV> perfect, thank you

GIM>> This is applicable to all BFD control packets transmitted over a VXLAN tunnel. To clarify, I propose the following change:
EV> ok, thank you

-- Section 4 --
EV> perfect

Why not using the Source MAC address as the Destination MAC address ? This
would ensure that there is no conflict at the expense of "forcing" the
transmission of the frame even if addressed to itself.
GIM>> Based on the input from experts familar with existing implementations, WG decided not to require the use of the specific MAC address. I think that using the Source MAC as the Destination might be one of the options an implementation will use.
EV> ok

-- Section 9 --
GIM>> Another input from experts familiar with VXLAN and its deployments reflected in the following:

EV> I do not want to discuss the HL=1 (cfr top of this email message) but more about requesting more information about the **attack vector** of packets with HL=1 ? E.g., it is about forcing the expired packet to the main CPU rather than data plane ASIC? Really unclear what the attack is with packet having HL=1

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 19 Dec 2019 13:06:10 -0500

Carlos,

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

> 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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 19 Dec 2019 20:12:56 +0000

Hi, Jeff,

> 2019/12/19 午後1:06、Jeffrey Haas <[email-masked]>のメール:
> 
> Carlos,
> 

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

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

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

> is intended for.  This leave us with roughly two modes:

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

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

> people about it actually helping.  So, don't insist on it for security

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.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 19 Dec 2019 15:38:04 -0500

Carlos,

> > 2019/12/19 午後1:06、Jeffrey Haas <[email-masked]>のメール:

Interesting.  You're a bit more multi-lingual that I knew. :-)

> 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., fro…

Right.  That was the host attack from within tenant space that I was talking
about earlier.  But as you note here, that can also be an external insertion
attack as well.

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

As Shepherd, you have my apologies then.  When I was reviewing the last set
of comments, I thought I had caught all flagged messages with your open
issues.  But as you may note, the threads went very long.

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

Specifically covering this issue.

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

That one did go to list traffic and I did take time to cover what I believed
was reasonable justification for not mentioning it.

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

I'm unclear what you're flagging here.  Yes, we can attack all sorts of
things here, but we're discussing very specifically TTL and its use in
mitigating attacks viz. GTSM.

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

See my prior ambivalence. :-)  It's reasonable modulo one of the two prior
implementations saying "this is a big deal!" to say "for our purposes, we
wish to use the security considerations of 5881".  As I noted for the IESG,
the considerations we have currently reflect 5884.  And while your
explanation for 5884's situation was helpful, I'm not entirely clear why the
vxlan encapsulation is so entirely different with regard to its impact vs.
MPLS and thus the 5884 scenario.

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

If there's at least one well articulated one, that's sufficient.  What I'm
trying to get talked into is that there is such reason where this really
helps.

If that's protecting vs. traffic that originates in the tenant's networking
space that hits the tunnel and happens to be destined to an inner-IP address
that is the tenant assigned address space that is not in the loopback
network address space, that'll do.  But it also feeds into my related
commentary on some considerations are scenario specific.  In particular, if
we're using the 5884 loopback network trick, you can't originate such
traffic from the tenant network.  (Hopefully the IESG reviewers have noted
this.)

-- Jeff

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 19 Dec 2019 21:38:29 +0000

Hi, Jeff,

Thanks for the dailogue and please see inline some follow-ups.

> 2019/12/19 午後3:38、Jeffrey Haas <[email-masked]>のメール:
> 
> Carlos,
> 

I can read Emoji :-) 

> issues.  But as you may note, the threads went very long.

Oh, no, no need. I think there’s shared responsibility between the editors, shepherd, and WG as a whole. But it really starts with the editors.

Not having an agreed-upon tracking system in the IETF does not help either…

While at it, though, out of the 6 issues brought up on that email, I only saw a response to issue #4 (and not we are discussing Issue #2). I would not mind the authors responding to the others :-) 

> MPLS and thus the 5884 scenario.

This is a most useful clarification and perhaps goes to the core of the different in perspective.

To me, RFC 5884 is not the most similar scenario to VXLAN. RFC 5884 concerns itself with a uni-directional label-swapping-or-popping-hop-by-hop paradigm where popping too many Label Stack Entries (LSEs) in-flight mid-tunnel would expose the inner packet to the point of being mis-forwarded and let loose in the core infrastructure. 

The same is not the case for VXLAN, which really seems more similar to RFC 5885 or 5881, the former saying:
      The Time to
      Live/Hop Limit and Generalized TTL Security Mechanism (GTSM)
      procedures from Section 5 of [RFC5881] apply to this
      encapsulation, and hence the TTL/Hop Limit is set to 255.

And while looking at this, the document seems to show further confusion around this.

S9 of https://tools.ietf.org/html/draft-ietf-bfd-vxlan-09 says:

   This document recommends using an address from the Internal host
   loopback addresses (127/8 range for IPv4 and
   0:0:0:0:0:FFFF:7F00:0/104 range for IPv6) as the destination IP
   address in the inner IP header.  Using such address prevents the
   forwarding of the encapsulated BFD control message by a transient
   node in case the VXLAN tunnel is broken as according to [RFC1812]:

However, a transient node cannot expose the Inner header since it does not understand VXLAN or the context of VXLAN… that’s the difference with MPLS... 

> traffic from the tenant network.  (Hopefully the IESG reviewers have noted

That’s exactly the case — traffic on the tenant’s network being tunneled. They are scenario-specific and thinner but non-null.

Your comment about the destination address being a loopback is useful. The document says SHOULD, not MUST use 127/8 or ::FFFF:127.0.0.0/104.

Thank you,

Carlos.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 20 Dec 2019 09:34:54 +0000

Jeffrey,

If you and the authors are ambivalent to HL=255, then I would suggest to stick to the original BFD spec and use HL=255

Regards

-éric

On 19/12/2019, 21:33, "iesg on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote: