> 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). Tom _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
