Hi Linda, I'm of course happy to meet up in SFO and chat. Ping me off list and we can find a time. BTW - I'm not sure I understand how DTLS plays a role here but we can chat when we chat. Cheers, S. On 20/07/2023 18:04, Linda Dunbar wrote:
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 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
Attachment:
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
