Subject: draft-ietf-ipngwg-icmp-v3-02.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 12 Feb 2002 21:33:07 -0500

In reviewing this ID prior to approving the IETF Last Call, I have the
following questions/comments:

> Rate limiting:
> 
>         The limit parameters (e.g., T or F in the above examples) MUST
>         be configurable for the node, with a conservative default value
>         (e.g., T = 0.5 second, NOT 0 seconds, or F = 2 percent, NOT 100
>         percent).

T= 0.5 seems fairly high. Why not .1 or .01 (on today's links).

It might also be useful to point out that having too much rate
limiting (in routers) causes problems for traceroute, since this has
been experienced in practice. Indeed, if routers rate limit to one
message every .5 seconds, today's traceroute would seem to become
unusable in practice. Indeed, even at .1 seconds, traceroute won't
hardly work anymore. I.e., the first probe will get trigger an ICMP
error, the second one (some 20-30 ms later) will not, due to rate
limiting, etc.

Would it be better to move away completely from fixed time intervals
and just say as a percentage of the link traffic? at least in the case
of routers?

So, question for the WG: Is the current text on this topic adequate,
or should it be revised?

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...

needs an IANA Considerations Section.

Should probably say something like "IANA guidelines for the assignment
of ICMP types and values are given in Section 7 of RFC 2780." This
assumes that the IANA section there is appropriate and doesn't need
updating.

It would also be appropriate to indicate what the IANA guidelines
should be for assigning new values for types defined in this
document. (Some probably would just say that IANA won't need to define
any, but some others probably need something more.)

One sentence abstract. RFC editor will likely say you can do better.
see http://www.rfc-editor.org/policy.html.

In the introduction (not the abstract), please add a line saying that
this document updates/replaces RFC 2463 (and add to references).

The reference section should separate the normative references from
those that are non-normative  (see http://www.rfc-editor.org/policy.html).

Thomas
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Feb 2002 10:41:10 +0200 (EET)

> So, question for the WG: Is the current text on this topic adequate,

Well, I brought up the issue with traceroute when I noticed some major 
router vendors implemented timer-based mechanisms, and proposed the 
token-bucket mechanism (which is used quite often).

Personally, I'm a bit unsatisfied how the examples are portrayed; IMO, 
timer-based should definitely go away, be put in last, huge disclaimers 
printed or whatever.

Bandwidth-based does not really scale: same implementation could be used 
over 64kbit/s or 10Gbit/s links.  What's the percentage there?  Assuming 
sending ICMP errors require processor cycles, the latter might still use 
up too much CPU even with 0.01% ;-) 

Also personally, token bucket is IMO the only sensible way to handle this.  

> thinking here since 2463 came out? 

ICMP, among others, can be used for many kinds of reflection attacks --
that is, like:

src = <victim>
dst = <router X>
informational ICMP packet

then router responds by sending (non-ratelimited) packets to <victim>, 
originated from <router X>.

You kill two birds with one stone: flood the victim by using any node 
anywhere, and in the process, kill the CPU on the reflector node. :-)

Mixing this with MIPv6 Home Address Option, the results would be even more 
disastrous.

Not that there is all that much to be done about this.. :-(

(this is partially discussed in draft-savola-ipv6-rh-ha-security-01.txt)

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Robert Elz <[email-masked]>
Date: Wed, 13 Feb 2002 16:16:16 +0700

Date:        Tue, 12 Feb 2002 21:33:07 -0500
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | Would it be better to move away completely from fixed time intervals
  | and just say as a percentage of the link traffic? at least in the case
  | of routers?

It should be revised, but should be specified as token bucket type
specifications - that is, it should be possible to send a burst of
ICMPs if they're needed, just as long as the long term rate doesn't
get above N (N can be pkts/sec, or percentage of packets processed).

The link traffic percentage model (alone) breaks down if there has been
no traffic (N% of 0 is 0, no matter what N is).

Make all rate limits be specified with a rate/second (and 2/sec, or T=0.5)
as a nice conservative default (just default) I can handle, but with a
burst count of about 20 (as dedfault) (10 seconds with none, and 20 can
be sent very quickly again).

  | So, question for the WG: Is the current text on this topic adequate,
  | or should it be revised?

Revise it.

kre

---

From: Francis Dupont <[email-masked]>
Date: Wed, 13 Feb 2002 10:41:10 +0100

In your previous mail you wrote:

=> I agree because T should be in milliseconds (f.1) and
is against back-to-back erroneous packets. I propose 20ms (50Hz).

=> it should be improved!

   
=> ESP cannot do authentication of the IPv6 header in transport mode,
I vote to leave the text (with "can be achieved..." which is only
an example).

   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)?

=> because of the authentication part of any SA establishment protocol.

   Note, this issue is one of the reasons why IPsec doesn't
   automatically solve the problem of authenticating MIPv6 BUs.
   
=> no, the problem with MIPv6 is the authentication phase can (must
in some cases) be done using a care-of address and the natural link
between addresses and identies must be reported into the policy.
There is no reason to do the same thing in the general case, i.e.
default policies shall reject such strange things (there was some
messages in the IPsec list about this).

   
=> I agree the wording can be improved but where is the proposal for
a new wording?

   ...
   
=> agree (we have to get better habits :-)

Regards

[email-masked]