[secdir] Secdir review of draft-ietf-lisp-type-iana-04

[Charlie Kaufman <[e-mail]>]

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document is: Ready

No security concerns.


This document proposes creation of two new IANA registries and defines a new message type within the Locator/ID Separation Protocol (RFC6830). The first registry should have been created by RFC6830, which assigned codes to 5 values for a four bit field. This document proposes creating a registry for holding those 5 values and a sixth value for the purpose of holding experimental extensions.


Because the 4 bit field can only ever support 16 values and several independent extensions are already being proposed, the proposal is to reserve the value 15 for experimental extensions where it has a 12 bit sub-type field to distinguish those extensions. This document proposes to create a second IANA registry for holding up to 4096 assigned values for that field, to be handed out on a first come first served basis.


While future extensions might have security implications, defining these new registries does not.


I don't know what IANA's experience has been with first come first served registries. With no review procedure, they are subject to abuse and I don't know who gets to exercise judgment as to whether a particular request is abusive.


The document states that the subtypes of value 15 are reserved for Experimental Use. My sense is that the intention of the authors is that should an experimental protocol be promoted to standards track that it will at that time be assigned on of the 16 values from the 4 bit field. This might be an unfortunate restriction for two reasons: 1) Given that there are only 16 types available and 6 have already been assigned, it seems possible that this space would eventually be exhausted; and 2) Requiring that protocols change syntax when they are promoted from experimental to standards track places a burden on implementers who often end up supporting both syntaxes indefinitely (and having interoperability problems if they don't). There's no reason obvious to me why subtypes could not be kept for standardized usage later. That is one of the advantages of having an IANA registry over reserving them for private use.


The intended status of this document is listed as Experimental. This seems wrong to me. While any future documents defining uses of newly assigned values might well be experimental, I would expect that this document would seek the same status as RFC6830 (and this document should be incorporated into any future revisions of that one).


--Charlie