Hi All,
I am trying to address Thomas Narten's comment on the security
consideration section of draft-ietf-ipngwg-icmp-v3-02.txt.
(See comments at the end of this mail)
Here is the proposed updated text. Please review it. I am trying
to submit the updated draft before Monday.
Regards
Mukesh
==================== 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.
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.
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.
==========================================================
=================== 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
--------------------------------------------------------------------
