Hi Tony and Watson，
Thank you for the comments.
I'd like to add the following text to the draft:
As outlined in Section 9.9 "Host Implementations" of [RIFT], hosts as well as VMs act as RIFT devices are possible.
KMP such as KV for key roll-over in the fabric using a symmetric key that can be changed easily when compromised. Wherein symmetric key of a host is more likely to be compromised than of a in-fabric networking node.
Will it make sense?
Best Regards,
Yuehua Wei
Original
From: AntoniPrzygienda <prz=40juniper.net@xxxxxxxxxxxxxx>
To: Watson Ladd <watsonbladd@xxxxxxxxx>;
Cc: secdir@xxxxxxxx <secdir@xxxxxxxx>;draft-ietf-rift-applicability.all@xxxxxxxx <draft-ietf-rift-applicability.all@xxxxxxxx>;last-call@xxxxxxxx <last-call@xxxxxxxx>;rift@xxxxxxxx <rift@xxxxxxxx>;
Date: 2024年04月19日 03:37
Subject: Re: [Rift] Secdir last call review of draft-ietf-rift-applicability-14
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
_______________________________________________
RIFT mailing list
RIFT@xxxxxxxx
https://www.ietf.org/mailman/listinfo/rift
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
_______________________________________________
RIFT mailing list
RIFT@xxxxxxxx
https://www.ietf.org/mailman/listinfo/rift
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
