http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/
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
Hey,
http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/
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
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:
Look at the slides 11 onwards.
Doing HMAC calculation for each packet adversely affects the number of
concurrent sessions that can be supported.
Glen.
Hey,
You might want to take a look at:
http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdfLook 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?
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.txtYou might want to take a look at:
http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdfLook 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.
IETF Proceedings -> 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
Dave Waters <davewaters1970@gmail.com> writes:
http://www.reddit.com/r/networking/comments/2vxj9u/very_elegant_and_a_simple_way_to_secure_bfd/
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
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:
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
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.
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...?
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