Review of draft-cheneau-csi-send-sig-agility-01

I have reviewed "Signature Algorithm Agility in the Secure Neighbor Discovery Protocol" and have the
following comments. I am not going to comment on the specifics of the protocol extension because I
disagree with the overall approach.

I do not think it's reasonable for an extension to a relatively simple security protocol (SEND) to
introduces 4 different types of hosts, 4 different type of routers, some of which are said to be "hard to
secure" and recommended to avoid, while another who rely on unspecified redirection mechanisms between
CGAs, and some combinations of these hosts and routers leading to undetectable failure modes (at least
from what I understood.)

I think most of the complexity and drawbacks of the proposal stems from the requirement that signature
agile nodes be able to negotiate a common signature algorithm, which I think is unreasonable when the
protocol employs multicast/broadcast (thus reaches multiples nodes which might support different
algorithms) and when the algorithm is somehow "hardcoded" in the CG address used by a node thus adding an
additional level of constraint.

In this situation, the only reasonable chance for ND to operate securely is that most of the nodes on a link
support the same signature algorithm (e.g., ECDSA), other minority nodes falling back to mixed mode.

In light of this, I recommend a simpler approach to be taken based on two simple requirements:

- it shall be possible for a node supporting the signature agility extension to use a public key algorithm
other than RSA for generation/verification of a signature/CGA.

- an ND message sent from a CGA based on a public key algorithm that is not supported by the receiver, and
signed using that same algorithm shall be treated as insecure by the receiver as per RFC3971, i.e., it
shall not be discarded.

--julien