The Secure Neighbor Discovery (SEND) Hash Threat Analysis
RFC 6273

Note: This ballot was opened for revision 12 and is now closed.

Lars Eggert (was Discuss) No Objection

Comment (2010-03-09)
No email
send info
COMMENT: AD, this document needs a ballot issued.

List of editorial nits sent directly to the authors.

(Pasi Eronen; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2010-03-10 for -)
No email
send info
Based on the SecDir reviews by Julien Laganier and Paul Hoffman, 
it seems this document needs a major rewrite (and one of the 
authors seems to agree):

(Jari Arkko; former steering group member) Yes

Yes (2010-03-10 for -)
No email
send info
Well written document, thanks. I had a few comments though:

Term ADD not defined.

> Theoretically this attack could harm
> SEND, but in real-world situation is to achieve it.

... is hard to achieve it?

> From the security
> point of view, at the moment, this solution is more reasonable
> then defining different hash algorithm for each hash.

... than defining ...?

> The computation of the Digital Signature field is described
> [rfc3971].

... described in?

> The computation of the Digital Signature field is described
> [rfc3971].  It is produced as the SHA-1 hash over the IPv6 addresses,
> the ICMPv6 header, the ND message and other fields, e.g. the Message
> Type Tag and ND options, and signed with the sender's private key.
> Private key corresponds to the public key in the CGA parameters
> structure.  It is usually authorized through CGAs.  

The signature field simply binds the private and public key together.
It works for both CGA and certificate-based SEND. Indeed, routers
use the certificate-based mode in practice exclusively.

> o  The third possible solution is to encode the algorithm in the CGA.
>    This would reduce the strength of the CGA and make it vulnerable
>    to brute force attacks.

... and also bidding down attacks, if I'm not mistaken. If the hash
algorithm is part of the CGA parameters structure, simply choose
a hash algorithm that is completely broken and find a value that
matches the victim's address AND uses the bad algorithm within the
CGA parameters structure.

> o  Possible solution is also the hybrid solution which would require
>    the hash algorithm to be the same as CGA, if CGA option is
>    present, and to use the Hash agility option if the CGA option is
>    not present.  In such way, SEND is not bound exclusively to CGA.

Isn't there also a hybrid solution where the hash is in the address
bits for CGA based addresses, and all certificate-related hash operations
are in the certificate? But maybe I'm missing something obvious.

> o  None of the previous solutions supports the negotiation of the
>    hash function.  One of possible solutions is the negotiation
>    approach for the SEND hash agility based on the Supported
>    Signature Algorithm option described in [sig-agility]. 

I would have noted the bidding-down issue already here (as you do
for some other alternatives).

> The negotiation approach for the hash agility in SEND based on the
> Supported Signature Algorithms option is vulnerable to bidding-down
> attacks, which is usual in the case of any negotiation approach.
> This issue can be mitigated with the appropriate local policies.

Perhaps some mitigation can be offered, but policy really isn't a
solution to the bidding down problem.

Anyway, the security consideration section kind of ends without
making a conclusion. My conclusion -- perhaps not surprisingly! --
is that the RFC 4982 approach seems to be valid approach. And this
is what current standards track specifications say. Do the authors
of this document want to change that situation, or not? It would be
useful to draw a conclusion.

(Ralph Droms; former steering group member) (was Discuss, Yes) Yes

Yes ()
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-03-11 for -)
No email
send info
There are a couple of minor warnings reported by idnits, and it would be good to fix these if a new revision of the document is being prepared.


Section 3.2


Section 3.2
   Even though real-world
   scenarios make SEND immune to recent hash attacks introduced through
   X.509 certificates, theoretically they are possible.

This feels like a contradiction or is confusing. If the attacks are possible, do we need to worry about them? If SEND is immune, we do not need to worry even if the attacks are easy and possible. If we *do* need to worry about them, then obviously SEND isn't immune.

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection (2010-03-11)
No email
send info
There are a significant number of typos in the document that detract from its readability.  


The first use of the acronym ‘SEND’ should be spelled out: /SEND/SEcure Neighbor Discovery (SEND)/

/Current SEND specification/The current SEND specification/

/for the hash algorithm agility/for hash algorithm agility/

/to provide analysis/to provide an analysis/

Section 1

/Cryptographically Generated Addresses (CGA)/Cryptographically Generated Addresses (CGAs)/

/Authorizaton Delegation Discovery/Authorization Delegation Discovery/


/First hash attacks/The initial hash attacks/


/Depending on the way how the Internet protocol uses the hash algorithm, Internet protocol can be affected/Depending on how the SEND protocol relies on the hash algorithm, Internet Protocol (IPv6) operation can be affected/

Section 3

/Up to date, all demonstrated attacks are attacks against a collision-free property./To date, all demonstrated attacks are attacks against the collision-free property./

/underlaying hash function/underlying hash function/

/no matter of the hash algorithm weaknesses/no matter the weaknesses of the hash algorithm/

/fingerprints/or fingerprints/

/on SEND by the cases of use/on SEND by the use cases/

/support the hash agility/support hash agility/

Section 3.2

/Router sends to a host/A router sends to a host/

/Potential problem for the attacker/The potential problem for the attacker/


/does not allowe to provide/does not allow/

/biggest concer are/the biggest concerns are/

/such human-readble data such would prevent attacks/such human-readable data would prevent attacks /

Section 3.3

/is described [rfc3971]/is described in [rfc3971]/

/Private key corresponds/The private key corresponds/

/The Digital Signature field the example of the non-repudiation digital singature/The Digital Signature field is an example of a non-repudiation digital signature/

/Possible attacks on such explicit digital signature/A possible attack on the Digital Signature field/

/He underlays one of the messages to be signed/The attacker signs one of the messages/

/but in real-world situation is to achieve it/but in real-world situations it seems difficult to achieve/

Section 3.4

/the integrity protection/integrity protection/

/the collision attacks/collision attacks/

/a non human-readable data/non human-readable data/

Section 4

/Previous section/The previous section/

/SEND context prevents/The SEND context prevents/

/The most effective and secure would be/The most effective and secure solution would be/

Section 6


/by providing solution for the hash agility support/by providing a solution to support hash agility/

(Ron Bonica; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2010-03-10 for -)
No email
send info
  Assuming Informational RFC.

  The Gen-ART Review by Pete McCann on 2010-03-09 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (2010-03-11 for -)
No email
send info
Please review the references to RFC 5709; some of these probably should be included as well.