comments on draft-davies-v6ops-icmpv6-filtering-bcp-00.txt

[Pekka Savola <pekkas@netcore.fi>]

I think the document is good and necessary one, but (IMHO) still (well, it's
a -00 version :) requires substantive work.  Note: I didn't look more than
about 5 pages or so, because the flight ended, but I think you get the
picture ;-)

1)

I think the most important issue is representation of the requirements and
summing them up.  That is, the recommendations should be categorized in
roughly following categories:

 * must not drop these messages (e.g., pkt too big)
 * should not drop these messages, think twice before you even consider it!
(most other ICMP errors)
 * these messages may be dropped but there's really no need to drop them
(redirects, ns/na, rs/ra, etc. -- things that the specifications say MUST be
discarded if they come from with hop count != 255 or link-local address
checks)
 * may or may not want to drop these
 * should consider dropping these messages (e.g., ICMP name lookups)

secondly, the messages/rules needed at the firewall to ensure its own
link-local messaging works OK should be separated from "transiting" messages
(split in categories like above).

further, the guidance needs to be summarized in some form: e.g., a table at
the end and/or very short pseudo-rules.

2) it may also already have come across above, but IMHO most of the
recommendations right now seem too strict and/or unnecessary.  I don't think
it's necessary to encourage the firewall admins to keep track of all the
ICMP types one by one (even with more precision than that in some cases),
and try to figure out how to deal with them.  We'll need to deal with the
messages by fixing sensible defaults, also to minimize the need for
continuous maintenance of the rules.

(Personally, I'm in favor accepting everything except maybe some some 
stupid [if used in inter-domain] messages like ICMP name lookups. 
For example, I don't think ICMP echo does any harm, due to the reasons 
described in Tim Chown's "port scanning considerations draft", but 
YMMV.)


semi-editorial
--------------

Abstract

 ==> the abstract is (comparatively) long for an I-D.  I'd try to cut it to
about a half.  (5-10 lines is probably a good ballpark figure.)  Less is
more :)

   o  Simple monitoring of connectivity through echo requests and
      responses used by the ping and traceroute utilities.  The Echo
      Request and Echo Response messages are specified in [RFC2463].

==> traceroute utils which use echo req/resp are, hopefully, relatively
rare, or are you referring to some more aggressive programs which e.g. first
do traceroute and then send a dozens of pings to each hop?

   o  Finding neighbors (both routers and hosts) connected to the same
      link and determining their IP and link layer addresses.  These
      messages are also used to check the uniqueness of any addresses
      that an interface proposes to use (Duplicate Address Detection -
      DAD)) - DAD can be turned off if the network administrator
      believes that the configuration method used is bound to generate
      unique addresses.  Four messages - Neighbor Solicitation (NS),
      Neighbor Advertisement (NA), Router Solicitation (RS) and Router
      Advertisement (RA) - are specified in [RFC2461].

==> in the interest of brevity, I'd remove the "DAD can be turned off"
debate from this (shorter) list of considerations/functions.  It can always
be described with the full considerations of DAD later in the doc.

   o  Redirecting packets to a more appropriate router on the local link
      for the destination address or pointing out that a destination is
      actually on the local link even if it is not obvious from the IP
      address (where a link supports multiple subnets).  This facility
      could be used by a malicious sender to divert packets and nodes
      should provide configuration options to prevent the messages being
      sent by routers and acted on by hosts.  The redirect message is
      specified in [RFC2461].

==> the same applies to redirects here; just say that it can only be used
on-link.

2.2  Addressing of ICMPv6

   ICMPv6 messages are sent using various kinds of source and
   destination address types.  The source address is usually a unicast
   address, but during address autoconfiguration message exchanges, the
   unspecified address :: is also used as a source address [RFC2462].

==> well, MLDv1 can also use it as src in some scenarios (see the RFC on
MLDv1 source address selection)..

2.3  Network Topology and Address Scopes

==> I think this section would use a lot of boosting w/ hop count=255
checks.  Personally, I find those pretty trustworthy, especially in addition
to (typically) having to use link-local addresses... (see my point above in
message types which don't really need to be blocked unless you want to make
pretty useless rules..)

3.3  Redirection Attacks

   These attacks would normally have to be carried out locally on a
   link, but it is important to ensure that Redirect messages are not
   allowed through the firewall.  Redirection could be used simply for
   DoS as well as endeavouring to redirect traffic to a compromised
   node.

==> redirects are very well protected by default, see above.

   addresses.  In some cases, where deeper packet inspection is
   possible, it may be desirable to filter on, for example, the Code
   field of ICMPv6 error messages.

==> I'd use a different example: ICMP type and code are, from the firewall
perspective, "equally deep"...

 Echo Requests travel end-to-end but never have
   a role in establishing communications.  Similarly Echo Responses
   (Type 129) travel end-to-end and would have a unicast address as
   destination and either a unicast or anycast address as source.

==> as the verifying node can't know whether it's uni- or anycast, I think
the point is moot, and you could just talk about unicast addresses..

editorial
---------

      that an interface proposes to use (Duplicate Address Detection -
      DAD)) - DAD can be turned off if the network administrator

==> add a '(' or remove a ')' around DAD ?

      specified in  Multicast Listener Discovery MLDv1 [RFC2710] and
      MLDv2[RFC3810].

==> s/MLDv2/MLDv2 /

   o  Providing support for some aspects of Mobile IPv6 especially
      dealing with the IPv6 Mobile Home Agent functionality provided in
      routers and needed to support a Mobile node homed on the link.
      The Home Agent Address Discovery Request and reply; and Mobile
      Prefix Solicitation and Advertisement messages are specified in
      [RFC3775]

==> something weird around "HA disc", the sentence doesn't parse?
missing a bullet point or something?

   Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be
   treated as an auxiliary function with packets that can be dropped in
   most cases without damaging the functionality of the network.  This
   means that firewall filters for ICMPv6 have to be more carefully
   configured than was the case for ICMP, where typically a small set of
   blanket rules could be applied.

==> maybe it would be simpler to just refer to ICMP as ICMPv4..

   to be sent to or pass through firewalls, and may be essential to the
   establishment of communications (see Section 2.4 whereas

==> missing ')'

   messages are any-to-end in nature.  Generally end-to-end and any-to-
   end messages might be expected to pass through firewalls depending on
   policies but local communications must not

==> something missing at the end ?


--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings