Re: draft-ietf-bfd-vxlan IESG status

[Greg Mirsky <[e-mail]>]

Hi Jeff,
thank you for the additional details. I've top-posted the discussion thread
regarding a firewall, VTEP, and drop rules. I recall that the relevant text
was suggested based on deployment experience. I will try to update it along
the suggested lines:

I think the rewording would include some phrasing like "RECOMMENDED that
the only firewall exception to allow incoming traffic with destination
address from the loopback range is when [...]", and of course, mention
the need to have BFD configured.

Would the following update make it clearer:
OLD TEXT:
  There could be a
   firewall configured on VTEP to block loopback addresses if set as the
   destination IP in the inner IP header.  It is RECOMMENDED to allow
   addresses from the loopback range through a firewall only if they are
   used as the destination IP addresses in the inner IP header and the
   destination UDP port is set to 3784 [RFC5881].
NEW TEXT:
  If a firewall
   configured on VTEP packets with their destination IP addresses in the
   inner IP header set to one of the loopback addresses listed above will be
   dropped.  To allow BFD work as described in this specification, it is
   RECOMMENDED to use an exception rule to allow addresses from the
   loopback range through a firewall only if they are used as the
   destination IP addresses in the inner IP header and the destination
   UDP port is set to 3784 [RFC5881].
Also, would splitting this text into a paragraph help to keep clear?

If the proposed update is not better than the current text, let's remove it
altogether.

Regards,
Greg

On Wed, Jun 17, 2020 at 12:52 PM Jeffrey Haas <[e-mail]> wrote:

> Greg,
>
>
> > On Jun 16, 2020, at 9:05 PM, Greg Mirsky <[e-mail]> wrote:
> > thank you for providing continued support and guidance. Please find my
> > notes in-lined under tag GIM>>. Attached are the new working version and
> > its diff to -12. There are two remaining Open Issues - 7 and 9. I much
> > appreciate your considerations and suggestions.
>
> [...]
>
> >>> Open Issue 7: "::FFFF:7F00:0/104 IPv6 range" (COMMENT via Benjamin K.)
> >>>
> >>> Proposed Action: I believe this issue's fate is similarly tied to Open
> >> Issue 3.
> >>> If the proposal is limited solely to management VNI, this text is not
> >>> relevant and may be deleted.
> >>
> >> This action is still pending.
> >>
> > GIM>> There are two references to this IPv6 range. I think that the
> > document should give a recommendation on what address to use as the
> > destination IP address. As we've discussed with  Adam Roach, only ::ffff:
> > 127.0.0.1/128 has host loopback meaning in IPv6. I propose to change
> > throughout the text from "one of the addresses from IPv6 range" to
> "::ffff:
> > 127.0.0.1/128 for IPv6".
>
> Sorry, the issue is from the IESG ballot at
> https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ballot/:
>
> >    0:0:0:0:0:FFFF:7F00:0/104 range for IPv6).  There could be a firewall
> >    configured on VTEP to block loopback addresses if set as the
> >    destination IP in the inner IP header.  It is RECOMMENDED to allow
> >    addresses from the loopback range through a firewall only if it is
> >    used as the destination IP address in the inner IP header, and the
> >    destination UDP port is set to 3784 [RFC5881].
> >
> > I think we should reword this to make it clear that the default behavior
> > is still "block all incoming traffic with loopback destination" and that
> > the exception is tightly scoped to the encapsulated VXLAN traffic
> > discussed in this document and the specific destination port *and when
> > BFD has been configured for the VTEP*.
>
> So, the question is what should be done about packet drop or firewalls?
>
> My opinion is one possible action for this is to drop the text.  For this
> feature to work, traffic will be arriving with packets destined to these
> well known ranges.  If you want the feature to work, they must be permitted
> to come through.  Rather than mention "if you have it", the related actions
> are implied by things necessary to implement it.
>
>
>
> >
> >>>
> >>> Open Issue 9: "Destination MAC: This MUST NOT be of one of tenant's MAC
> >>> addresses." (COMMENT via Benjamin K.)
> >>>
> >>> Proposed Action: I believe this issue's fate is similarly tied to Open
> >> Issue 3.
> >>> If the proposal is limited solely to management VNI, this text is not
> >>> relevant and may be deleted.
> >>
> >> In -12, we now have the following text:
> >> "Destination MAC: since a Management VNI is the VNI that does
> >> not have any tenants, the value of this field is not analyzed
> >> by the receiving VTEP."
> >>
> >> For the management VNI, this text is true.  However, it likely requires
> a
> >> value that is described in the specification.
> >>
> >> Proposed solution: A MAC value should be chosen that is well known and
> th=
> > e
> >> text would become:
> >>
> >> "Destination MAC: A Management VNI, which does not have any tenants,
> will
> >> have no dedicated MAC address for decapsulated traffic.  The value
> >> X:X:X:X:X
> >> SHOULD be used in this field."
> >>
> >> SHOULD might need to be MUST.  Since a partial motivation for permitting
> >> the
> >> flexibility in the specification to NOT use the management VNI is
> desired=
> > ,
> >> MUST might be inappropriate.
> >>
> > GIM>> Accepted the suggested text. I agree that the flexibility to not
> use
> > the Management VNI is permitted in the specification and thus SHOULD in
> the
> > text is consistent with that scenario. How would we pick the MAC address?
>
> I am out of my area of expertise and I was hoping someone in the IESG can
> offer a fix. :-)  I am copying Donald Eastlake since he's the designated
> expert for the IANA MAC address block.
>
> Donald, review of the thread may be useful, but tersely the need is to
> have a well known MAC address that can be placed in this vxlan PDU that is
> literally a placeholder of "not to be used for forwarding".  The packet
> arrives at the endpoint and, if not immediately accepted, would be dropped.
>
> If there is no well known MAC that could be used for such a behavior,
> perhaps an address from the IANA block may be used?
>
> While I suspect the IANA mac documentation range could be used, IANA may
> not appreciate that.
>
> -- Jeff
>
>
>