Re: [Rift] Nitpicks on RIFT model

[Antoni Przygienda <[e-mail]>]

cc:'ing rift list in case anyone else likes to obsess a bit about it ;-)

yes, we can do that except I will still call things inner security key. I prefered to have one constant but yes, I was fudging one is u8 the other is u24 really so what you suggest is cleaner

--- tony
________________________________
From: Bruno Rijsman <[e-mail]>
Sent: Sunday, July 21, 2019 6:02 AM
To: Antoni Przygienda <[e-mail]>
Subject: Re: Nitpicks on RIFT model

At least in the model that I am looking at, there is no SecurityKeyID, there is only OuterSecurityID, InnerSecurityKeyID, and TIESecurityKeyID.

IMHO the following would be the most correct (note correct typing, names consistent with rest of draft, and more consistent underscore_naming vs CamelCaseNaming):

/** outer security key id (must be treated as unsigned) */
typedef i8 OuterSecurityKeyID

/** undefined outer security key id */
const OuterSecurityKeyID undefined_outer_security_key_id = 0;

/** TIE origin security key id (must be treated as unsigned) */
typedef i32 TIEOriginSecurityKeyID

/** undefined tie origin security key id */
const TIEOriginSecurityKeyID undefined_tie_origin_security_key_id = 0;

— Bruno

PS: For the sake of openness and letting the area directors know that discussion is happening, start CC’ing the mailing list?

On Jul 21, 2019, at 12:41 AM, Antoni Przygienda <[e-mail]<mailto:[e-mail]>> wrote:

done, will be in -07, no version changes

I left in the SEcurtykeyid to suport the undefined_key constant which is important

--- tony

________________________________
From: Antoni Przygienda <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, July 20, 2019 6:25 PM
To: Bruno Rijsman <[e-mail]<mailto:[e-mail]>>
Subject: Re: Nitpicks on RIFT model

aha, careful reading


  1.  ok, I'll clean up the types incl. unsigned
  2.  the keys have been added so you can check on top of the fabric whether the links have been secured and by which key. Now, I consider normal model would be for people to secure whole fabric and check that e.g. key roll-overs worked that way but if one assumes e.g. the ToF can be compromised then yes, it presents a risk to a degree. Your proposal otherwise? and yes, local significance is clera, just like we flood local link IDs the outer key is local

________________________________
From: Bruno Rijsman <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, July 20, 2019 3:51 AM
To: Antoni Przygienda <[e-mail]<mailto:[e-mail]>>
Subject: Nitpicks on RIFT model

Hey Tony,

I just noticed something new in draft-ietf-rift-rift-06 (relative to draft-ietf-rift-rift-05):

  /** outer security key id */
  typedef i8            OuterSecurityKeyID
  /** outer security key id */
  typedef i32           InnerSecurityKeyID
  /** security key id */
  typedef i32           TIESecurityKeyID

The InnerSecurityKeyID is not used anywhere else in the model, and should probably be removed, since the concept of an inner key has been replaced by the concept of a TIE origin key.

The TIESecurityKeyID is not also used anywhere else in the mode. It should probably also be removed, but if it needs to be kept for some reason, the comment should be updated (TIE origin security key id), the name should be updated (TIEOrigin instead of TIE for the sake of consistency) and the comment should mention it is unsigned 24 bits.

We should probably also explicitly mention that all the KeyID types should be treated as unsigned as well (since we do that in other places where integers should be treated as unsigned).

And a more subtle and much more nit-picky comment: adding OuterSecurityKeyID to LinkIDPair is little bit dangerous because outer security key IDs could be locally significant (that is why 8 bits instead of 24 bits is enough). So, if we flood that “this link uses outer key id 17” over the entire network, then there is no guarantee that “outer key id 17” means the same thing everything in the network: outer key id 17 could mean key “this-is-top-secret” on one link, and the same outer key id 17 could mean key “my-fantastic-password” on another node in the same network (at least hypothetically - but we could say “don’t do that”).

Question: why was OuterSecurityKeyID added to LinkIDPair in the fist place? Just for easier debugging or something more than that?

— Bruno