Stephen,
Thanks for the chat during IETF117.
Section 3.1.4 has been revised to address your comment #3 on trust-on-first-use (TOFU) .
The Zero-Touch-Provisioning (ZTP) for a remote SD-WAN edge describes the steps to address the TOFU:
- The SD-WAN edge’s customer information and its device identifier, such as the device series number, are added to the SD-WAN Central Controller.
- Upon power-up, the SD-WAN edge can establish the transport layer secure connection (such as TLS, DTLS) [BCP195] to its controller, whose URL (or IP address) can be preconfigured on the edge device by manufacture default, external USB or secure Email given to the installer.
- The SD-WAN Controller authenticates the ZTP request from the remote SD-WAN edge with its configurations. Once the authentication is successful, it can designate a local network controller near the SD-WAN edge to pass down the initial configurations via the secure TLS/DTLS secure channel.
Can you please check the revision -15 https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/ to see if all your comments have
been addressed? If yes, can you please change your SECDIR review option on the IETF Data Tracker?
Thank you very much,
Linda
_____________________________________________
From: Linda Dunbar
Sent: Thursday, July 20, 2023 12:05 PM
To: Stephen Farrell <stephen.farrell@xxxxxxxxx>; secdir@xxxxxxxx
Cc: bess@xxxxxxxx; draft-ietf-bess-bgp-sdwan-usage.all@xxxxxxxx; last-call@xxxxxxxx
Subject: RE: Secdir last call review of draft-ietf-bess-bgp-sdwan-usage-14
From: Linda Dunbar
Sent: Thursday, July 20, 2023 12:05 PM
To: Stephen Farrell <stephen.farrell@xxxxxxxxx>; secdir@xxxxxxxx
Cc: bess@xxxxxxxx; draft-ietf-bess-bgp-sdwan-usage.all@xxxxxxxx; last-call@xxxxxxxx
Subject: RE: Secdir last call review of draft-ietf-bess-bgp-sdwan-usage-14
Stephen,
Thank you very much for the review and comments. Sorry for the delayed response
Resolution to your suggested are inserted below. Revised draft will be posted next week when the IETF submission opens.
Linda
-----Original Message-----
From: Stephen Farrell via Datatracker <noreply@xxxxxxxx>
Sent: Monday, July 17, 2023 4:52 PM
To: secdir@xxxxxxxx
Cc: bess@xxxxxxxx; draft-ietf-bess-bgp-sdwan-usage.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Secdir last call review of draft-ietf-bess-bgp-sdwan-usage-14
From: Stephen Farrell via Datatracker <noreply@xxxxxxxx>
Sent: Monday, July 17, 2023 4:52 PM
To: secdir@xxxxxxxx
Cc: bess@xxxxxxxx; draft-ietf-bess-bgp-sdwan-usage.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Secdir last call review of draft-ietf-bess-bgp-sdwan-usage-14
Reviewer: Stephen Farrell
Review result: Not Ready
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
[Linda] Removed all reference to SSL in the document.
- "(TLS, DTLS, etc.)." seems like a variation of that but is there a
real DTLS option here?,
[Linda] TLS is for TCP traffic. DTLS is for UDP traffic. Is there anything wrong by mentioning both?
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.)
[Linda] is referencing BCP195 same as referencing RFC8996 and RFC9325?
#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.
[Linda] Removed DES, 3DES. Added AES256, AES192, AES128. Should “Blowfish” be added? Also changed the Hash algorithm options to SHA2 512, SHA2 384, SHA2256.
#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.)
[Linda] do you have time during IETF for a chat on this topic?
Linda
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
