Re: [Rift] Security review of draft-ietf-rift-rift-05 is now complete

[Tony Przygienda <[e-mail]>]

2.3.1. So filled in a bit of the missing details on the nonce
interpretation in LIEs. In fact, the draft on bitbucket says currently

"...

Any secure implementation MUST discard packets
where its local nonce is not correctly mirrored but it may choose to
either refuse forming an adjacency with an implementation not
advertising signatures or valid nonces or simply keep on signing
local packets while accepting neighbor's packets without further
verification beside checking for proper nonce reflection.

As a necessary exception, an implementation MUST advertise
`undefined_nonce` for remote nonce value when the FSM is not in 2-way
or 3-way state and accept an `undefined_nonce` for its local nonce
value on packets in any other state than 3-way.
"

With that being said it looks to me like 2.3.1 attack is not possible.
a 3-way will keep steady and not care whetehr any LIEs with 0 nonce
are replayed and just ignore them. Maybe language needs bit
clarification

2.3.2 is correct, it's a limited DoS attack on the protocol, kind of
as intended. Perfect security including perfect replay security is
often more expensive than what is being protected here like bits of
extra CPU (where re-flooding is dampened). Usual security mantra:
the safe has to be less  expesive than what's inside but cost more to
crack than what's in it, otherwise security does not make economic
sense ;-)

2.3.3 is correct as well, just like in 2.3.2 increasing nonces on
every TIDE is possible of course and would close that window but we
have to chat about the performance implications. So I agree with
sentiment but experience/scar tissue speaks against the sentiment.

2.5.2 is solved by Appendix A explaining rollover in detail. What
needs to be added, just the "roll-over over 0?" ... We may have a
problem with 0 being "undefined nonce" already, bares discussing out
... Maybe we need add that on rollover when 0 is the value, it must
immediately go to 1?

2.6. yes, spec was missing the new text I wrote above. That should
prevent replays to shut down a 3-way and take care of the problem you
describe.

2.6.2 is interesting, what your take? we have to always check the
outer key before looking @ nonce. I thought taht was understood but we
can add text ...

2.7 Your table says it all, having SHA-265 (which isn't very strong)
doing only 20K @ 9K MTU is a problem so I disagree with your
conclusion. SHA-512 doing 14K is way lower than flooding rates
I see easily now so sorry, it's way, way too slow ...
AFAIK MD5 is already history even as signature and AFAIR e.g. for FIPS
not allowed.  Yes, asymmetric signing is very slow, validation is much
faster AFAIU. So yes, nothing changed, doing 100K @ couple KB packets
doing
serious signatures is too expensive. Maybe we can make the delta
configurable but then you'll have very fragile adjhacency
configuration. An implementation can BTW easily put a knob like that
in ...

2.9. I think the correct way to distribute certificaties inline is KV
! The KV draft is still pending to be written and it's a great topic
for that BTW ... ;-)

2.10 is a good optimization, given especially that the object is the
biggest part so flooding out we'll save tons of CPU when outer
envelope (lifetime) changes. Should we include that?

 2.11 section 5.4.3 is really not something that needs to be
spefcified. It's how the implemenation chooses to scope keys, can be
per adjacency, can be global. It's local behavior

3.2

a) relying on strictly increasing numbers reads well but is fragile
from deployment experience on PNNI. One lost or misordered packets can
reset adjacency, pretty disastrous so many implementation have
interesting "additions" to deal with that AFAIR which amount to delta
on nonces we use in some variant ;-) Deployment experience & scar
tissue.
Link state protocols do misorder and they loose, it's a fact of life.
The faster you go the worse it gets and loosing an adjacnecy can cause
quite sensational amount of flooding on normal protocols and
given disaggregation, even in RIFT can be costly. In deployments
normnally, "do not loose adjacenies" is much, much more important than
"perfect replay security" ...

b) if you use different nonces for TIE/TIDE and so on you'd have to
negotiate them per packet type? That's infeasible IMO.

c) I need to read up the karp-ospf-ip draft again. AFAIR it was
complex but I forgot details. will come back and let's see whether
there are more comments on the list ...

So, security folks, fire away, I think the analysis is very, very
thorough and the few points raised need shaking out ...

--- tony


















On Wed, May 1, 2019 at 9:43 AM Bruno Rijsman <[e-mail]> wrote:

> My security review of draft-ietf-rift-rift-05 is now complete and
> available at http://bit.ly/rift-security-review
>
> — Bruno
>
> On Apr 23, 2019, at 10:41 AM, Bruno Rijsman <[e-mail]>
> wrote:
>
> PS: Due to other activities, it will take me a week or two to finish the
> write-up of my comments on the security section of the RIFT draft. I want
> to make sure my write-up is accurate and complete before I send it out,
> because some of my comments are quite subtle or opinionated.
>
> — Bruno
>
>
> _______________________________________________
> RIFT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rift
>