http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple... Authentication mechanisms defined for IGPs cannot be used to protect BFD since the rate at which packets are processed in BFD is very high. Dave
On (2015-02-15 21:34 +0530), Dave Waters wrote: Hey,
http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple...
Authentication mechanisms defined for IGPs cannot be used to protect BFD since the rate at which packets are processed in BFD is very high.
Not sure I understand the draft[0] correctly, but I suppose it only protects you from forced state-change attack. Attacker can't force you to go from up=>down or down=>up, but attacker could force routers to keep BFD state? I wonder if Trio, EZChip and friends could do SHA in NPU, my guess is yes they could, but perhaps there is even more appropriate hash for this use-case. I'm not entirely convinced doing hash for each BFD packet is impractical. [0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt -- ++ytti
I wonder if Trio, EZChip and friends could do SHA in NPU, my guess is yes they could, but perhaps there is even more appropriate hash for this use-case. I'm not entirely convinced doing hash for each BFD packet is impractical.
[0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt
You might want to take a look at: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf Look at the slides 11 onwards. Doing HMAC calculation for each packet adversely affects the number of concurrent sessions that can be supported. Glen.
-- ++ytti
On (2015-02-16 08:55 +0530), Glen Kent wrote: Hey,
You might want to take a look at: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf
Look at the slides 11 onwards.
Doing HMAC calculation for each packet adversely affects the number of concurrent sessions that can be supported.
I don't understand the slidedeck. Lets take slide 13, 'hardware support' for authentication. Why in quotes? What hardware is doing the hashing here? Which hash algo? How many cycles per byte for BFD how many more for BFD with algoX? On x86 CPUs it's anything from 1 to 20 cycles per byte, depending on hash algorithm, but HW implementation would be much more efficient. Of course if HW is done serial to the BFD receive/send, then there is non-zero performance cost regardless of how fast the HW is. Separate parallel HW implementation is probably not practical today, as you'd need to use what ever primitives your NPU has? So practical question would ask, what algo is implementable in Trio/EZchip and how would it impact the cycles per BFD packet? Page 14 appears to be only slide doing HW in auth, but I can't be sure, as first example claims 'auth in soft', second does not. Is there only one example in whole slidedeck with auth in hardware, if so, how come ratio in the first example and last examaple in page 14 is same 1/8th, implying HW brings 0 benefit? -- ++ytti
Mon, Feb 16, 2015 at 08:55:17AM +0530, Glen Kent wrote:
I wonder if Trio, EZChip and friends could do SHA in NPU, my guess is yes they could, but perhaps there is even more appropriate hash for this use-case. I'm not entirely convinced doing hash for each BFD packet is impractical.
[0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt
You might want to take a look at: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf
Look at the slides 11 onwards.
Were these people doing some real implementation in-hardware or were just theoretizing? I see "prediction" label for the number of authenticated sessions -- do you have an idea what that means? And on slide 14 you have smaller session limit numbers for BFD fully implemented in hardware than for hw-assisted case (slide 12). It makes me think that this presentation should either be supplemented with talking people or there are some errors in it. Or I am completely missing some fine point here.
Doing HMAC calculation for each packet adversely affects the number of concurrent sessions that can be supported.
Without mentioning the scope (which hardware and software) this assertion is either trivial or useless, sorry. TSO, frame checksums and other stuff hadn't been implemented in-hardware for ages, but now it is here and there all the time. And /me is interested why can't BFD be done on the interface chip level: it is point-to-point on L2 for the majority of cases. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
http://www.ietf.org/proceedings/90/agenda.html -> MPLS WG was heldin Sovereign on 4th March @ 1300-1400 http://www.ietf.org/audio/ietf89/ will you the audio recording for this talk.
From the MOM http://www.ietf.org/proceedings/89/minutes/minutes-89-mpls its clear that there is no disagreement about NOT doing BFD authentication in hardware -- similar to what is claimed by the presenter.
I think the hardware used was Broadcom. They have a few chipsets which do MD5 and (possibly) SHA in hardware for BFD -- which i have been told is pretty much useless when you start scaling. Glen On Mon, Feb 16, 2015 at 8:20 PM, Eygene Ryabinkin <rea@grid.kiae.ru> wrote:
Mon, Feb 16, 2015 at 08:55:17AM +0530, Glen Kent wrote:
I wonder if Trio, EZChip and friends could do SHA in NPU, my guess is yes they could, but perhaps there is even more appropriate hash for this use-case. I'm not entirely convinced doing hash for each BFD packet is impractical.
[0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt
You might want to take a look at: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf
Look at the slides 11 onwards.
Were these people doing some real implementation in-hardware or were just theoretizing? I see "prediction" label for the number of authenticated sessions -- do you have an idea what that means?
And on slide 14 you have smaller session limit numbers for BFD fully implemented in hardware than for hw-assisted case (slide 12).
It makes me think that this presentation should either be supplemented with talking people or there are some errors in it. Or I am completely missing some fine point here.
Doing HMAC calculation for each packet adversely affects the number of concurrent sessions that can be supported.
Without mentioning the scope (which hardware and software) this assertion is either trivial or useless, sorry. TSO, frame checksums and other stuff hadn't been implemented in-hardware for ages, but now it is here and there all the time.
And /me is interested why can't BFD be done on the interface chip level: it is point-to-point on L2 for the majority of cases. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute"
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
On (2015-02-17 06:11 +0530), Glen Kent wrote:
I think the hardware used was Broadcom. They have a few chipsets which do MD5 and (possibly) SHA in hardware for BFD -- which i have been told is pretty much useless when you start scaling.
Thanks. I'd be more interested to see performance for Trio, EZChip and perhaps even pq3/qoriq SEC2/SEC3. Real platforms, deployed in volume today. but I guess this data, at least for Trio would be very difficult to acquire. However pq3/qoriq would, in my mind, be software implementation, as it's control-plane CPU, which means BFD would have to be punted as well. -- ++ytti
On (2015-02-17 06:11 +0530), Glen Kent wrote:
I think the hardware used was Broadcom. They have a few chipsets which do MD5 and (possibly) SHA in hardware for BFD -- which i have been told is pretty much useless when you start scaling.
While I don¹t fully understand the context of this particular test and the scaling limitation, there are merchant silicon, NPUs and even CPUs that do support MD5 and SHA at transport line rate requirements. BFD requirements are just a fraction of these capabilities. The option to negotiate capabilities should be available independent of scaling/cost/inefficiencies at present time. It is a matter of implementation/product design choice. Sudeep Khuraijam
Dave Waters <davewaters1970@gmail.com> writes:
http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple...
Authentication mechanisms defined for IGPs cannot be used to protect BFD since the rate at which packets are processed in BFD is very high.
Dave
One might profitably ask why BFD wasn't designed to take advantage of high-TTL-shadowing, a la draft-gill-btsh. -r
Because BFD packets can get routed across multiple hops. Unlike EBGP where you connect to a peer in a different AS and you have a direct connection, BFD packets can traverse multiple hops to reach the endpoint. In case of multihop BFD the BFD packets also get re-routed when the topology changes so you can almost never bet on the TTL value to secure the protocol. Dave On Tue, Feb 17, 2015 at 7:03 AM, Rob Seastrom <rs@seastrom.com> wrote:
Dave Waters <davewaters1970@gmail.com> writes:
http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple...
Authentication mechanisms defined for IGPs cannot be used to protect BFD since the rate at which packets are processed in BFD is very high.
Dave
One might profitably ask why BFD wasn't designed to take advantage of high-TTL-shadowing, a la draft-gill-btsh.
-r
Many moons ago, Mike O'Dell had a pithy observation about "can" vs. "should" that is escaping me at this moment, which is a pity since it almost certainly applies here. -r Dave Waters <davewaters1970@gmail.com> writes:
Because BFD packets can get routed across multiple hops. Unlike EBGP where you connect to a peer in a different AS and you have a direct connection, BFD packets can traverse multiple hops to reach the endpoint.
In case of multihop BFD the BFD packets also get re-routed when the topology changes so you can almost never bet on the TTL value to secure the protocol.
Dave
On Tue, Feb 17, 2015 at 7:03 AM, Rob Seastrom <[[rs@seastrom.com]]> wrote:
Dave Waters <[[davewaters1970@gmail.com]]> writes:
> [[http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple...]] > > Authentication mechanisms defined for IGPs cannot be used to protect BFD > since the rate at which packets are processed in BFD is very high. > > Dave
One might profitably ask why BFD wasn't designed to take advantage of high-TTL-shadowing, a la draft-gill-btsh.
-r
Because BFD packets can get routed across multiple hops. Unlike EBGP where you connect to a peer in a different AS and you have a direct connection, BFD packets can traverse multiple hops to reach the endpoint.
Then what's this "multihop" knob I have available in my BGP config? Again, as Rob pointed out, "can" vs. "should" is a good consideration here, but unless I'm missing something both EBGP and BFD "can" do multihop...so...? -- Hugo On Tue 2015-Feb-17 07:42:20 +0530, Dave Waters <davewaters1970@gmail.com> wrote:
Because BFD packets can get routed across multiple hops. Unlike EBGP where you connect to a peer in a different AS and you have a direct connection, BFD packets can traverse multiple hops to reach the endpoint.
In case of multihop BFD the BFD packets also get re-routed when the topology changes so you can almost never bet on the TTL value to secure the protocol.
Dave
On Tue, Feb 17, 2015 at 7:03 AM, Rob Seastrom <rs@seastrom.com> wrote:
Dave Waters <davewaters1970@gmail.com> writes:
http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple...
Authentication mechanisms defined for IGPs cannot be used to protect BFD since the rate at which packets are processed in BFD is very high.
Dave
One might profitably ask why BFD wasn't designed to take advantage of high-TTL-shadowing, a la draft-gill-btsh.
-r
On (2015-02-16 20:33 -0500), Rob Seastrom wrote: Hey,
One might profitably ask why BFD wasn't designed to take advantage of high-TTL-shadowing, a la draft-gill-btsh.
RFC5881, section 5 in page 4 --- If BFD authentication is not in use on a session, all BFD Control packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255. All received BFD Control packets that are demultiplexed to the session MUST be discarded if the received TTL or Hop Limit is not equal to 255. A discussion of this mechanism can be found in [GTSM]. --- -- ++ytti
participants (7)
-
Dave Waters -
Eygene Ryabinkin -
Glen Kent -
Hugo Slabbert -
Rob Seastrom -
Saku Ytti -
Sudeep Khuraijam