Fair comment. Yes, VMs could participate and it merits a discussion though RIFT already has a section 9.9 on end system implementation and key considerations attached to it. Further, thinking through what you say,I see that the applicability draft could be more specific on using e.g. KV for key roll-over, i.e. the fabric using a symmetric key pretty much that can be changed easily when compromised and here yes, it could indicate that it could easily support end-system well-known symmetric that can be changed when compromised contrary to a in-fabric (i.e. networking nodes) key that is less likely to be compromised. — Tony > On 18 Apr 2024, at 21:27, Watson Ladd <watsonbladd@xxxxxxxxx> wrote: > > [External Email. Be cautious of content] > > > On Thu, Apr 18, 2024 at 12:18 PM Antoni Przygienda <prz@xxxxxxxxxxx> wrote: >> >> Hmm, surprising comment a bit … >> >> RIFT draft has a serious security section in 6.9 and a serious security considerations sections in section 9 and IMO it belongs there. AFAIS those section cover extensively security models possible and all kind of threats/consdierations on secure implementations. Of course lots of that could be moved into applicability (should it? Is security “applicability” even and if so, which part of it? Guide how to deploy it securely? ) but I don’t think that’s the intention and I’m bits lost further what “specificity” means here specifically ;-) e.g. Key management considerations do not seem particularly specific to rift as a protocol AFAIS unless what is desired is some RFC reference that describes key management in routing protocols and the pluses/minuses . > > As an example of the kind of interaction I'm thinking about RIFT says > "use one symmetric key for ZRT". The applicability document seems (and > maybe I'm wrong in this) to have VMs directly participate in the > fabric for mobility. That means all VMs have the symmetric key. You > probably don't want that. > > Sincerely, > Watson Ladd -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
