base.txt | issue69.txt | |||
---|---|---|---|---|
skipping to change at page 42, line 24 | skipping to change at page 42, line 24 | |||
List or Default Router List. The Neighbor Cache SHOULD implement | List or Default Router List. The Neighbor Cache SHOULD implement | |||
a flag on entries indicating whether the entry issecured. | a flag on entries indicating whether the entry issecured. | |||
Received secured messages MUST cause an update of the matching | Received secured messages MUST cause an update of the matching | |||
entries and flagging of them as secured. | entries and flagging of them as secured. | |||
o The conceptual sending algorithm is modified so that an insecure | o The conceptual sending algorithm is modified so that an insecure | |||
router is selected only if there is no reachable SEND router for | router is selected only if there is no reachable SEND router for | |||
the prefix. That is, the algorithm for selecting a default router | the prefix. That is, the algorithm for selecting a default router | |||
favors reachable SEND routers over reachable non-SEND ones. | favors reachable SEND routers over reachable non-SEND ones. | |||
o A node MAY adopt an insecure router, including a SEND router for | ||||
which full security checks have not yet been completed, while | ||||
security checking for the SEND router is underway. Security | ||||
checks in this case include delegation chain solicitation, | ||||
certificate verification, CRL checks, and RA signature checks. A | ||||
node MAY also adopt an insecure router if a SEND router becomes | ||||
unreachable, but SHOULD attempt to find a SEND router as soon as | ||||
possible, since the unreachability may be the result of an attack. | ||||
Note that while this can speed up attachment to a new network, | ||||
accepting an insecure router opens the node to possible attacks, | ||||
and nodes that choose to accept insecure routers do so at their | ||||
own risk. The node SHOULD in any case prefer the SEND router as | ||||
soon as one is available with completed security checks. | ||||
o A SEND node SHOULD have a configuration option that causes it to | o A SEND node SHOULD have a configuration option that causes it to | |||
ignore all insecure Neighbor Solicitation and Advertisement, | ignore all insecure Neighbor Solicitation and Advertisement, | |||
Router Solicitation and Advertisement, and Redirect messages. | Router Solicitation and Advertisement, and Redirect messages. | |||
This can be used to enforce SEND-only networks. | This can be used to enforce SEND-only networks. | |||
9. Security Considerations | 9. Security Considerations | |||
9.1 Threats to the Local Link Not Covered by SEND | 9.1 Threats to the Local Link Not Covered by SEND | |||
SEND does not provide confidentiality for NDP communications. | SEND does not provide confidentiality for NDP communications. | |||
End of changes. | ||||
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |