I mostly agree with Thomas' comments. A couple of additional points inline:
==================== Proposed updated text =============== 5. Security Considerations
5.1 Authentication and Confidentiality of ICMP messages
ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH] or IP Encapsulating Security Payload Header [IPv6-ESP]. Confidentiality for the ICMP protocol packet exchanges can be achieved using IP Encapsulating Security Payload Header [IPv6-ESP]. A node SHOULD include an Authentication Header or Encapsulating Security Payload Header when sending ICMP messages if a security association for use with the IP Authentication Header or IP Encapsulating Security Payload Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol.
The primary problem with this is that while you may know well your peer and even be able to set up a security association with him, it may not be easy to set up security associations with all the routers (and their operators) in between. Perhaps you should mention something about this.
Received ICMP packets that have Authentication Header or Encapsulating Security Payload Header must be processed as specified in [IPv6-AUTH] and [IPv6-ESP]. The ICMP packets that fail the security processing MUST be ignored and discarded.
It SHOULD be possible for the system administrator to configure a node to ignore any ICMP messages that are not authenticated using either the Authentication Header or Encapsulating Security Payload. Such a switch SHOULD default to allowing unauthenticated messages.
5.2 ICMP Attacks
ICMP messages may be subject to various attacks. A complete discussion can be found in the IP Security Architecture [IPv6-SA]. A brief discussion of such attacks and their prevention is as follows:
1. ICMP messages may be subject to actions intended to cause the receiver to believe the message came from a different source than the message originator. In some cases, the protection against this attack can be achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message.
2. ICMP messages may be subject to actions intended to cause the message or the reply to it go to a destination different than the message originator's intention. In some cases, the protection against this attack can be achieved using the Authentication Header or the Encapsulating Security Payload Header as the source and the destination addresses are protected against change when the Authentication Header or the Encapsulating Security Payload Header is used.
Actually, the point about the checksum may have been relevant. I think the attack you are describing here is that someone in the middle change the destination address of an ICMP message, right? ESP does not protect the IP header, but the fact that the addresses from the header are included in the pseudo-header that is calculated into the checksum helps. The checksum is covered by ESP, so that can not be changed. Anyway, that protection may not be quite as strong as AH/ESP gives you otherwise. Presumably you would have to test for 2^15 different fake addresses before you found one that would give the same checksum value, no?
3. ICMP messages may be subject to changes in the message fields, or payload. The authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message is a protection against such actions.
4. ICMP messages may be used as attempts to perform denial of service attacks by sending back to back erroneous IP packets. An implementation that correctly followed section 2.4, paragraph (f) of this specifications, would be protected by the ICMP error rate limiting mechanism.
There may be some additional ICMP issues related to DoS that you should mention. There are two exceptions in the multicast rule e.2 in Section 2.4. In theory, you could cause a very large number of nodes to send you Packet Too Bigs or Parameter Problems. For instance, just send a multicast packet with an unknown option marked as mandatory. Fortunately, it turns out that its relatively hard to get the multicast routers to carry your fake multicast packet unless you are on the correct multicast path, i.e. very near the legitimate sender. But perhaps you should say something about this too.
==========================================================
=================== Thomas's comments ====================
security considerations could perhaps use some updating. It seems largely
unchanged relative to RFC 2463. Has nothing really changed in our
thinking here since 2463 came out?
It doesn't seem to note that ESP can do authentication only now. Should ESP (w/o encryption) also be used if an SA exists?
1. ICMP messages may be subject to actions intended to cause the receiver to believe the message came from a different source than the message originator. The protection against this attack can be achieved by applying the IPv6 Authentication mechanism [IPv6-AUTH] to the ICMP message.
add "in some cases"? There is an authorization questioned buried here. How does one know that a particular SA is authorized to speak on behalf of a particular IP address (or actually came from the message originator)? Note, this issue is one of the reasons why IPsec doesn't automatically solve the problem of authenticating MIPv6 BUs.
2. ICMP messages may be subject to actions intended to cause the message or the reply to it go to a destination different than the message originator's intention. The ICMP checksum calculation provides a protection mechanism against changes by a malicious interceptor in the destination and source address of the IP packet carrying that message, provided the ICMP checksum field is protected against change by authentication [IPv6-AUTH] or encryption [IPv6-ESP] of the ICMP message.
seems like if you have AH/ESP, that check alone provides you the additional protection. That it also covers the ICMP checksum is not really relevant... ==========================================================
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
