Skip to main content

Last Call Review of draft-ietf-bess-bgp-sdwan-usage-14
review-ietf-bess-bgp-sdwan-usage-14-secdir-lc-farrell-2023-07-17-00

Request Review of draft-ietf-bess-bgp-sdwan-usage
Requested revision No specific revision (document currently at 23)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2023-08-01
Requested 2023-07-11
Authors Linda Dunbar , Ali Sajassi , John Drake , Basil Najem , Susan Hares
I-D last updated 2023-07-17
Completed reviews Secdir Last Call review of -19 by Stephen Farrell (diff)
Secdir Telechat review of -20 by Stephen Farrell (diff)
Intdir Telechat review of -16 by Juan-Carlos Zúñiga (diff)
Secdir Telechat review of -15 by Stephen Farrell (diff)
Secdir Last Call review of -14 by Stephen Farrell (diff)
Genart Last Call review of -14 by Dan Romascanu (diff)
Rtgdir Early review of -06 by Shuping Peng (diff)
Assignment Reviewer Stephen Farrell
State Completed
Request Last Call review on draft-ietf-bess-bgp-sdwan-usage by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/P8JYYa0iLYeC8PljHaqsWyeLumc
Reviewed revision 14 (document currently at 23)
Result Not ready
Completed 2023-07-17
review-ietf-bess-bgp-sdwan-usage-14-secdir-lc-farrell-2023-07-17-00
I have two easily fixed issues and one that may need a bit of chat:

#1 There are a few places with (probably wrong) security text that
really would be better fixed. Those include:

- "(such as TLS, SSL, etc.)" occurs a few times, but SSL just isn't a
  thing we'd recommend
- "(TLS, DTLS, etc.)." seems like a variation of that but is there a
  real DTLS option here?, 

I'd suggest fixing all those to just say TLS maybe with a reference
to BCP 195, but the exact fix should be fairly obvious to anyone who
is familiar with how TLS can really be used in this context. (I'm not
asking that you say "you MUST use TLS" here, just that you say what
can actually be done with realistically available tooling.)

#2 There's also a really 20th century bit of (probably wrong)
security text "(DES, 3DES, or AES)" - again checking with someone
familiar with how IPsec can be useful here should result in text that
makes sense.

#3 I'm just not clear on the security model here. I recognise that
this is just an informational document but I did not understand how
one could avoid a trust-on-first-use (TOFU) or leap-of-faith if one
sets up a system as described, and I doubt that TOFU is what everyone
setting up such systems would want. I suspect that may be down to
just not having quite enough text about how to configure security
things here, but am unsure and a quick glance at the references
([SECURE-EVPN] and RFC9012) didn't clarify that for me. (Mostly as
those are more complex than the time I had to spend on this today;-)
It could be that I'm just not understanding the text, or that there
are some more security considerations or other text to add, e.g. to
say how to avoid TOFU, should that be what one wants, but I'm just
not sure based on the text as-is. (BTW, if the reality is that nobody
actually has a "zero-touch" way to configure IPsec, or if TLS just
isn't usable, then it'd be better to say that than to sorta-pretend
those are usable, but again, I don't know what's realistic here
today.)