Subject: Re: draft-vinokour-bfd-dhcp-01.txt

From: Nitin Bahadur <[email-masked]>
Date: Wed, 30 Jul 2008 22:57:32 +0100

Hi Vitali,

  I have some comments regarding your draft draft-vinokour-bfd-dhcp-01.txt
I believe the intentions of the draft are good. But the main question I have
is - is this going to scale? DHCP server serves thousands of clients. You
are talking about running BFD for each of these clients. Won't the DHCP
server be a bottleneck?

  If you alleviate scaling concerns by using failure detection intervals in
the order of a few seconds, then my question is - is using BFD then worth
it? If there is a failure (today, without BFD), are there cases where the
failure is NOT detected within a few seconds.

 Basically, I am not 100% convinced of the motivation for the solution.

My other comments are as below:

1) Your draft aims at boot-strapping the BFD session with BFD parameters.
IMO, this is not a good idea. BFD parameters are local to a box and
shouldn't be dictated by a remote end. BFD relies on parameter negotiation
and your draft doesn't support that. The DHCP client could be running on a
low-CPU box and I think it's better to have default BFD config on the client
rather than have the server dictate what to use.

2) Authentication seems like an issue here. You seem to be passing the
authentication keys from server to client. So how are you protecting the
keys...in other words, if someone can snoop on the keys, then someone can do
nasty things. Also, it seemed to me that the key is going to be the same for
both all clients (unless you provision a unique key per client..which
doesn't sound scalable to me from a provisioning point of view on the
server) and in both directions. This seems like a security hole (if I
understand the draft correctly).

3) The draft does not say whether the BFD session is going to be single-hop
or multi-hop.

4) You have copied (almost) the entire bfd header in the dhcp server
response. I don't think this is the right approach. BFD fields have nothing
to do with DHCP (like the C-bit). As I said earlier, negotiate, negotiate
and negotiate. The only field I see really necessary is the "remote ip
address".

5) Since the remote ip address is typically not known by hosts (as you say),
then is making it known now (via the new dhcp tlv) acceptable? That's more
of a question for the DHCP folks I guess

6) Why does the BFD version need to be 1 ? BFD version negotiation
procedures should negotiate the version. The *current version* could be 2
when someone goes to implement the RFC. They will get confused by the RFC.

Thanks
Nitin

---

From: "Vitali Vinokour (vvinokou)" <[email-masked]>
Date: Wed, 30 Jul 2008 22:39:56 -0400

Hi Nitin,

Thanks for your comments. Please see inline. 

> -----Original Message-----
> From: Nitin Bahadur [mailto:[email-masked]] 
> Sent: Wednesday, July 30, 2008 5:58 PM
> To: [email-masked]; Vitali Vinokour (vvinokou)
> Subject: Re: draft-vinokour-bfd-dhcp-01.txt
> 
> Hi Vitali,
> 
>   I have some comments regarding your draft 
> draft-vinokour-bfd-dhcp-01.txt I believe the intentions of 
> the draft are good. But the main question I have is - is this 
> going to scale? DHCP server serves thousands of clients. You 
> are talking about running BFD for each of these clients. 
> Won't the DHCP server be a bottleneck?
> 

DHCP server is configuring the clients anyway. This is a standard
broadband scenario. We are just adding an option containing BFD
configuration to DHCP messages. 

>   If you alleviate scaling concerns by using failure 
> detection intervals in the order of a few seconds, then my 
> question is - is using BFD then worth it? If there is a 
> failure (today, without BFD), are there cases where the 

There is currently no credible mechanism for CPE to detect layer 3
connectivity failure not accompanied by an l2 link failure; none at all.
BFD is proposed as a keepalive for IP sessions for exactly that reason. 

>  Basically, I am not 100% convinced of the motivation for the 

While the draft primarily describes bootstrapping of BFD by DHCP on a
CPE the motivation for running BFD between IP CPE and IP Edge is to
detect IP connectivity failures. As I said, there is no established
mechanism for it today.

> IMO, this is not a good idea. BFD parameters are local to a 
> box and shouldn't be dictated by a remote end. BFD relies on 
> parameter negotiation and your draft doesn't support that. 
> The DHCP client could be running on a low-CPU box and I think 
> it's better to have default BFD config on the client rather 
> than have the server dictate what to use.
> 

The parameters that DHCP is conveying to CPE are not the ones that BFD
end point can negotiate. E.g. BFD does not negotiate Desired Min Tx
Interval or Required Min Rx Interval; these values are supposed to be
present in the very first message a BFD peer sends out and are supplied
by a bootstrapping application. In this case bootstrapping application
is DHCP; it happens to be distributed between server and client but it
does not change BFD bootstrapping methodology. 

Note that this draft is targeting routing gateways that are typically
under SP control; so DHCP server (configured by the same SP) will be in
the position to provide BFD config matching CPE capabilities.

> 2) Authentication seems like an issue here. You seem to be 
> passing the authentication keys from server to client. So how 
> are you protecting the keys...in other words, if someone can 
> snoop on the keys, then someone can do nasty things. Also, it 
> seemed to me that the key is going to be the same for both 
> all clients (unless you provision a unique key per 
> client..which doesn't sound scalable to me from a 
> provisioning point of view on the
> server) and in both directions. This seems like a security 
> hole (if I understand the draft correctly).
> 

Please refer to the Security section of the draft: "To ensure security
of
   authentication keys, DHCP messages containing options TBD_3 or TBD_4
   with BFD authentication information MUST be authenticated using the
   procedures described in [RFC3118]."

In any case, it is not expected that BFD authentication will be used in
broadband networks. These networks have native security mechanisms (e.g.
L2 isolation).

> 3) The draft does not say whether the BFD session is going to 
> be single-hop or multi-hop.

It does not matter. 

> 
> 4) You have copied (almost) the entire bfd header in the dhcp 
> server response. I don't think this is the right approach. 
> BFD fields have nothing to do with DHCP (like the C-bit). As 
> I said earlier, negotiate, negotiate and negotiate. The only 
> field I see really necessary is the "remote ip address".
> 

Please see earlier response (to your comment 1).

> 5) Since the remote ip address is typically not known by 
> hosts (as you say), then is making it known now (via the new 
> dhcp tlv) acceptable? That's more of a question for the DHCP 
> folks I guess
> 

Yes it is perfectly acceptable and is very similar to functionality of
well-established DHCP options. See e.g. RFC 2241, it defines an option
for specifying NDS servers to clients. 

> 6) Why does the BFD version need to be 1 ? BFD version 
> negotiation procedures should negotiate the version. The 
> *current version* could be 2 when someone goes to implement 
> the RFC. They will get confused by the RFC.
> 

Yes I agree, BFD version should be set to the currentBFD version.

Thanks,
Vitali

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 01 Aug 2008 02:10:17 +0100

Hi Vitali,

  Thanks for the prompt response! Please see inline below for some
clarifications.

> configuration to DHCP messages.

Let me re-phrase my query. My scaling concern is regarding running thousands
of BFD sessions from a DHCP server. If a DHCP server runs BFD to each of
it's 30,000 clients, then the DHCP server might just die.
 
> detect IP connectivity failures. As I said, there is no established

I understand that motivation. But that motivation only holds true if your
DHCP server can sustain tens of thousands of BFD sessions to the edge.

> does not change BFD bootstrapping methodology.

I think you have misunderstood how BFD works. I'll explain with an example.
You can run BFD over OSPF neighbors today to detect fast failure of an OSPF
neighbor. In this case, OSPF programs BFD (OSPF is the client of BFD). But
there is *NO* OSPF signaling involved. Each OSPF peer individually programs
BFD based on whatever parameters each system seems as correct. The detection
times are based off the peer's advertised values and the local system's
values. I repeat, you DO NOT need to send over timing parameters in DHCP
negotiation. You *DO NOT* need to signal any *bfd flags* to the peer to make
BFD.

> the position to provide BFD config matching CPE capabilities.

You cannot write a draft that makes generic changes in DHCP and assume that
no one else should implement it for their own scenario. Your above
explanation of one system assuming the capabilities of the other systems is
a bad assumption IMO.
 
> broadband networks. These networks have native security mechanisms (e.g.

This is a security issue. Please take advice of other IETF experts and clean
up this section. If BFD auth is not expected to be used then it should not
be defined in DHCP.
 
>> be single-hop or multi-hop.

It DOES matter. BFD packets are sent to different ports based on whether
this is single-hop or multi-hop. If the draft does not specify whether the
session is single-hop or multi-hop, then the session might never come up.
 
> Please see earlier response (to your comment 1).

Doesn't hold. You have misunderstood how BFD works.
 
> Yes I agree, BFD version should be set to the currentBFD version.

Why does the BFD version needs to be set to the current version? I fail to
understand. The BFD version should be set to the version that the box
supports. If the box doesn't support version 1, then how can the box set it
to version 1 ? Version field is there to specify the version a box supports.

It seems like you are trying to solve the problem for a *very specific*
case, a case in which scaling might not be an issue. I am not clear on the
applicability of the draft. But given that the changes proposed are generic,
one could potentially run BFD between a DHCP server and my good old 800 MHz
Linux desktop. The draft should probably specify the applicability. If the
applicability is not generic enough, then it should be clarified.

In any case, I fail to see why anything besides the BFD capability and the
"remote peer address" are needed to make this work.

Thanks
Nitin

---

From: "Vitali Vinokour (vvinokou)" <[email-masked]>
Date: Fri, 1 Aug 2008 04:59:09 -0400

Nitin,

Please see inline. 

> Sent: Thursday, July 31, 2008 9:10 PM
> To: Vitali Vinokour (vvinokou); [email-masked]
>   Thanks for the prompt response! Please see inline below for 
> some clarifications.
> 
> the draft 
> >> are good. But the main question I have is - is this going 
> to scale? 
> >> DHCP server serves thousands of clients. You are talking about 
> >> running BFD for each of these clients.
> Let me re-phrase my query. My scaling concern is regarding 
> running thousands of BFD sessions from a DHCP server. If a 
> DHCP server runs BFD to each of it's 30,000 clients, then the 
> DHCP server might just die.
>  

In a typical broadband scenario, BRAS acting as DHCP server or Relay
serves tens of thousands of IP subscribers. The draft explains how BFD
can be configured by DHCP server OR relay. In other words: when  BRAS is
acting as DHCP server, it is perfectly fine for that server to run
30,000 BFD sessions; it does scale by design. In the case of a DHCP
server not collocated with BRAS, the BFD sessions terminate on the DHCP
relay.  

> >>   If you alleviate scaling concerns by using failure detection 
> >> intervals in the order of a few seconds, then my question is - is 
> >> using BFD then worth it? If there is a failure (today, 
> without BFD), 
> >> are there cases where the failure is NOT detected within a few 
> >> seconds.
> >> 
> I understand that motivation. But that motivation only holds 
> true if your DHCP server can sustain tens of thousands of BFD 
> sessions to the edge.
> 

See above.

> >> shouldn't be dictated by a remote end. BFD relies on parameter 
> >> negotiation and your draft doesn't support that.
> >> The DHCP client could be running on a low-CPU box and I think it's 
> >> better to have default BFD config on the client rather 
> than have the 
> > present in the very first message a BFD peer sends out and are 
> > supplied by a bootstrapping application. In this case bootstrapping 
> > application is DHCP; it happens to be distributed between 
> server and 
> > client but it does not change BFD bootstrapping methodology.
> 
> You can run BFD over OSPF neighbors today to detect fast 
> failure of an OSPF neighbor. In this case, OSPF programs BFD 
> (OSPF is the client of BFD). But there is *NO* OSPF signaling 
> involved. Each OSPF peer individually programs BFD based on 
> whatever parameters each system seems as correct. The 
> detection times are based off the peer's advertised values 
> and the local system's values. I repeat, you DO NOT need to 
> send over timing parameters in DHCP negotiation. You *DO NOT* 
> need to signal any *bfd flags* to the peer to make BFD.
> 

You do not need to send timing or other BFD parameters over to an OSPF
peer because you can configure them locally on each peer. CPE routers
are not configured locally; their configuration is either hard coded or
dynamically provisioned via DHCP. Are you suggesting hard coding BFD
parameters into each CPE? This is pretty much the only way to avoid some
kind of remote configuration. 

Note that the whole purpose of DHCP is to deliever *local* host
configuration dynamically from a remote server. So it is quite feasible,
from DHCP point of view, to deliver BFD configuration of the CPE. From
BFD point of view, the only difference is that the bootstrapping
function is "distributed" between DHCP server and client. 

> > under SP control; so DHCP server (configured by the same 
> SP) will be 
> > in the position to provide BFD config matching CPE capabilities.
> 
> You cannot write a draft that makes generic changes in DHCP 
> and assume that no one else should implement it for their own 
> scenario. Your above explanation of one system assuming the 
> capabilities of the other systems is a bad assumption IMO.
>

The mechanism proposed in the draft is applicable to any DHCP scenario.
If specific CPE capabilities are not known to the administrator
configuring the server the default should be used; any CPE supporting
BFD should be able to run with default configuration. The functionality
does not depend on the assumption that DHCP server is aware of CPE
capabilities. 
  
> >> 2) Authentication seems like an issue here. You seem to be passing 
> >> the authentication keys from server to client. So how are you 
> >> protecting the keys...in other words, if someone can snoop on the 
> >> keys, then someone can do nasty things. Also, it seemed to me that 
> >> the key is going to be the same for both all clients (unless you 
> >> provision a unique key per client..which doesn't sound 
> scalable to me 
> >> from a provisioning point of view on the
> > In any case, it is not expected that BFD authentication 
> will be used 
> > in broadband networks. These networks have native security 
> mechanisms (e.g.
> > L2 isolation).
> 
> This is a security issue. Please take advice of other IETF 
> experts and clean up this section. If BFD auth is not 
> expected to be used then it should not be defined in DHCP.
>  

What exactly is a security issue? Please be more specifc. Authentication
per 3118 ensures secure transmission of BFD keys; this mechanism was
added in response to concerns of IETF experts. 

> >> 3) The draft does not say whether the BFD session is going to be 
> >> single-hop or multi-hop.
> > 
> > It does not matter.
> 
> It DOES matter. BFD packets are sent to different ports based 
> on whether this is single-hop or multi-hop. If the draft does 
> not specify whether the session is single-hop or multi-hop, 
> then the session might never come up.
>  

Yes, I agree. Whether BFD session is single hop or multihop should be
specified by a configuration flag.

> >> response. I don't think this is the right approach.
> >> BFD fields have nothing to do with DHCP (like the C-bit). 
> As I said 
> >> earlier, negotiate, negotiate and negotiate. The only field I see 
> >> really necessary is the "remote ip address".
> >> 
> > 
> >> procedures should negotiate the version. The *current 
> version* could 
> >> be 2 when someone goes to implement the RFC. They will get 
> confused 
> >> by the RFC.
> >> 
> > 
> Why does the BFD version needs to be set to the current 
> version? I fail to understand. The BFD version should be set 
> to the version that the box supports. If the box doesn't 
> support version 1, then how can the box set it to version 1 ? 
> Version field is there to specify the version a box supports.
> 

The version should be set to the version which the BRAS supports. If CPE
does not support BRAS version, it will fail to come up anyway.

> It seems like you are trying to solve the problem for a *very 
> specific* case, a case in which scaling might not be an 
> issue. I am not clear on the applicability of the draft. But 
> given that the changes proposed are generic, one could 
> potentially run BFD between a DHCP server and my good old 800 
> MHz Linux desktop. The draft should probably specify the 
> applicability. If the applicability is not generic enough, 
> then it should be clarified.
> 

Use of DHCP in broadband netowrks can hardly be classified as very
specific. And there is nothing in the draft that precludes its use
between any DHCP server and client.

Thanks,
Vitali

> In any case, I fail to see why anything besides the BFD 
> capability and the "remote peer address" are needed to make this work.
> 
> Thanks
> Nitin
> 
>