Re: [Last-Call] Tsvart last call review of draft-ietf-bfd-unsolicited-11

[Naiming Shen <naiming@xxxxxxxxxx>]

Hi Magnus,

Thanks again for the comments and discussions. See more replies inline with <NS2>…</NS2>

On Nov 22, 2022, at 03:09, Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx> wrote:

Hi,

 

Please see inline for my comments prefix with [MW].

 

 

> b) "Limit the feature to specific
> interfaces, and to single-hop BFD with "TTL=255"
>     [RFC5082]." I would think that this sentence would rather state that one
>     MUST use the RFC 5082 security mechanism for the BFD traffic. What is
>     unclear to me from not having read RFC 5082 in detail is if this mechanism
>     works well for this traffic or gets additional traffic into problems due
>     to scoping which appear to be interface wide. Thus, are further
>     clarifications on usage needed?

<NS>
This sentence is just to state one of the key requirements of the ‘unsolicited-bfd’ that:
 - to enable the feature for specific interfaces of a device
 - only valid for single-hop BFD
 - to use the TTL=255 check describe in RFC-5082

Those are the key operational and protocol requirements due to the security consideration.
Not much further clarification we can add on.
</NS>

[MW] Maybe I didn’t expressed myself clear enough. First, can you clarify that TTL=255 (RFC5082) is a MUST use? I think that can be stated clearer and using RFC 2119 language.

 

Secondly, my question around the usage of TTL=255 was that it appeared to be bound to an interface, rather than a specific port. So are no other traffic on this interface other than next hop? Or is RFC 5082 unclear of how to handle situation of applying it beyond the IP header?

 

<NS2>

Ok. Yes we meant this TTL=255 to be a MUST use for ‘unsolicited-bfd’, also specified by RFC5881. Will add that and reference to RFC5881 in updated version.

The usage of TTL=255 is specific to BFD packets, in specific to this unsolicited-bfd case Single-Hop BFD packets, where the packet inbound interface must be checked to see if explicitly configured for ‘unsolicited-bfd’ feature; and also the BFD is a IP/UDP in which IP packet TTL has to be 255 in value. This TTL requirement has nothing to do with the interface with other IP packets.

</NS2>

 

> c) "Use BFD authentication, see [RFC5880]. In some environments, e.g. when
> using an IXP, BFD authentication can not be used because of the lack of
> coordination into the operation of the two endpoints of the BFD session. In
> other environments, e.g. when BFD is used to track the next hop of static
> routes, it is possible to use BFD authentication: this comes with the extra
> cost of configuring matching key-chains at the two endpoints. If BFD
> authentication is used, the Meticulous Keyed SHA1 mechanism SHOULD be used."
> This mitigation usage is deployment dependent, thus better care in formulation
> related to this is needed. This appears to be a MUST unless in this particular
> situation and should be clearer. Also the actual support required for interop
> appears a bit weak without having looked into RFC 5880 in detail. But only a
> SHOULD support algorithm?

<NS>
Because ‘unsolicited-bfd’, like normal BFD, can be used in various environments, some in
more secure and internal, others at less secure locations. Different types of authentication
can be used and different security algorithm types can be used by network operators.
This draft does not want to specify in general which algorithm must be used. It only points
out in certain conditions, a more secure algorithm should be used.
</NS>

Okay, I will leave this one to the Sec Ads to consider. But for situations like this, I would have expected there to be at least one mandatory to implement algorithm for interoperability, and a clear statement on the exception cases for usage. 

 

 

> 
> 2) Not being an expert in BFD and its control parts it appears that there are
> no mechanism for terminating an ongoing BFD session as the passive player in
> case of any overload. It is even unclear if there are any other mechanism than
> refusing to respond to a new session for the passive entity when getting
> unsolicitied BFD. So it would be good if the document could be more explicit if
> there are any action the passive entity can do if ending up with to many BFD
> sessions? I understand the goal here is to limit the number of potential peers
> as well as ensuring that they are trusted entities even before any packets are
> sent, but are there really no method to stop the session?

<NS>
Since it’s a ‘passive’ and no configuration is needed for this ‘unsolicited-bfd’ mechanism,
it does not have an explicit way of terminating a particular ongoing session from protocol
point of view. An analogy would be if a website does not use mTLS mechanism, only uses
TLS, the protocol will not have an explicit way to terminate a HTTPs session. But if the
device is overloaded due to the number of ‘unsolicited-bfd’ sessions on an interface,
the operators can ‘Apply “policy” to allow BFD packets only from certain subnets or hosts’
(stated also in the Security Consideration section). For instance, if 10.1.0.0/16 ACL is too
broad in this case, the operators can replay 10.1.5.0/24 to limit the source IP address further,
or even 10.1.5.64/26, etc. This should enable them to reset the current sessions, and reduce
the total ‘unsolicited-bfd’ sessions to the desired number if needed.
</NS>

So you state by restricting what the BFD reply server answers in a policy you will time out the others and they will actually stop? That sounds contradicting to some of the usages of BFD that is intended to detect when the path exists between the two entities. And unless I misunderstand this paragraph it is not required to do this only recommended:

 

   The passive side MUST then start sending BFD Control packets and

   perform the necessary procedure for bringing up, maintaining and

   tearing down the BFD session.  If the BFD session fails to get

   established within certain specified time, or if an established BFD

   session goes down, the passive side SHOULD stop sending BFD Control

   packets and MAY delete the BFD session created until BFD Control

   packets are initiated by the active side again.

 

 

I also think mutual TLS is a poor choice of example here. Because either versions of TLS will be sent over a transport protocol and for all realistic alternatives that can carry TLS the transport protocol can be terminated to stop further communication or possibly connect and then tell the higher layer protocol to go away.

 

I think the issue I see here is that in some configurations of unsolicited BFD the passive entity can have to simply accept that all single IP hop nodes can start a session against it and it may not be able to stop that traffic. Yes, BFD is not particular high bandwidth normally. So this protocol have some potentially problematic aspects, which likely is not going to cause issues. But if would cause issues it will take some work to sort things out.

<NS2>

When we say ‘Applying policy’ for the ‘unsolicited-bfd' packets for certain subnet and hosts, it’s outside of BFD protocol mechanism and it refers to some generic capabilities on the device. E.g. the operators can apply an ACL/Firewall on this interface (which configured for ‘unsolicited-bfd’) to filter out all the BFD inbound packets where source IP does not match 10.1.5.65 and is not 10.1.5.68, basically in this example to only allow two sessions maximum to exist for ‘unsolicited-bfd’  (others will timeout if there were on-going sessions). But normally the ACL should be reasonable to allow say 10.1.5.0/24 on the subnet of the interface and not to bother with specific host IP. We agree with your statement that it’s not a high data bandwidth feature.

</NS2>

 

> 
> 3) Section 7.2:
> So this section lays out the "knobs" that are sensitive. But it appears to not
> really put any requirement on that one actually protects. Is this how things
> usually are done i YANG modules?
> 

<NS>
This is a general statement, in ‘unsolicited-bfd’ configure mechanism, there is no sensitive
information. we may remove this section from the updated draft.
</NS>
> 

I think the knobs you point out are fairly sensitive from an authorization perspective. So I think it is right to point them out.

<NS2>

Ok.

</NS2>

Cheers,

- Naiming

 

Cheers

 

Magnus

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call