Subject: ICMPv3: Security Consideration Section.

From: [email-masked]
Date: Wed, 11 Feb 2004 21:59:51 -0600

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Feb 2004 08:17:35 +0200

I mostly agree with Thomas' comments. A couple of additional points

>    through manual configuration or through the operation of some key

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.

>       the Authentication Header or the Encapsulating Security Payload

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?

>       of this specifications, would be protected by the ICMP error rate

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.

--Jari