> On Jul 29, 2016, at 2:59 PM, Tom Herbert <[email protected]> wrote: > >> As a hypothetical question, how would you handle a situation where the >> security token you have defined for GUE is shown to be broken and needs to >> be replaced with a new option? I’m sure that in that case, you would feel >> the need to react immediately. It seems like the two choices would be to >> start using one of the unallocated flag fields and standardize and migrate >> before there is a collision with another option or resort to the private >> data field. Both seem to have some downsides. > > The security option is defined with length(s) but no semantics. The > particular security algorithm used between two hosts is done out of > band agreement (key exchange is needed anyway). The only case where we > need to reconsider security this is when we need a larger token, in > that case we can define an extended security field option (but we > already have a 32 bit option, more than that and we're starting to > majorly impact MTU).. > > The transform option contains an 8 bit transform type. Right now the > value for DTLS is defined, more transform types can be defined as > needed (we allow for private transform types also).
Sorry, I should have been clearer - security was mostly just framing for the question on extensibility. The general point that I was trying to make was that there are a variety of cases where having open ended extensibility is useful. At least in some situations it’s probably important to be able to react to and deploy new options very quickly. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
