[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WGLC: draft-ietf-v6ops-icmpv6-filtering-recs-02
On Fri, Jul 21, 2006 at 08:42:22PM -0700, Fred Baker wrote:
> David:
>
> The WGLC on the recent icmp recommendations draft has commpleted
> without comment, either public or (Elwyn tells me) private. I think
> you're in a position to continue your review.
>
> Fred
Hi,
I have a handful of minor comments. In general I think the document
is very usefukl and should be published. I have not rechecked
Appendix A or B.
Abstract
In networks supporting IPv6 the Internet Control Message Protocol
version 6 (ICMPv6) plays a fundamental role with a large number of
functions, and a correspondingly large number of message types and
options. ICMPv6 is essential to the functioning of IPv6 but there
are a number of security risks associated with uncontrolled
forwarding of ICMPv6 messages. Filtering strategies designed for the
corresponding protocol, ICMP, in IPv4 networks are not directly
>> I'd add something here like you state in the main text to catch a
reader's attention as to why IPv4-like ICMP filtering practice is
not good for IPv6.
>> The audience should certainly be firewall vendors as well as site admins.
>> Maybe also emphasise it's INformational, seeking feedback to go BCP?
1. Introduction
When a network supports IPv6 [RFC2460], the Internet Control Message
Protocol version 6 (ICMPv6) [RFC4443], [I-D.ietf-ipngwg-icmp-v3]
>> The I.D reference is redundant now and can be deleted?
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.
>> So a bit of this text would be good in the abstract, if it can fit.
2.3. Network Topology and Address Scopes
Local communications will use link-local addresses in many cases but
may also use global unicast addresses when configuring global
addresses, for example.
>> Or ULAs when configuring ULA addresses. Though they are global scope now.
Also some ICMPv6 messages used in local
communications may contravene the usual rules requiring compatible
scopes for source and destination addresses.
>> Maybe add an example?
3. Security Considerations
Firewalls will normally be used to monitor ICMPv6 to control the
following security concerns:
>> Firewalls and/or IDS systems? Often combined, but not always.
>> RFC4443 has a security considerations section. It might be helpful to
a reader of that document and this if the subsections were congruent, or
is that not possible?
3.3. Redirection Attacks
A redirection attack could be used by a malicious sender to perform
man-in-the-middle attacks or divert packets either to a malicious
monitor or to cause DoS by blackholing the packets. These attacks
would normally have to be carried out locally on a link using the
Redirect message. Administrators need to decide if the improvement
in efficiency from using Redirect messages is worth the risk of
malicious use. Factors to consider include the physical security of
the link and the complexity of addressing on the link. For example,
on a wireless link, redirection would be a serious hazard due to the
lack of physical security. On the other hand, with a wired link in a
secure building with complex addressing and redundant routers, the
efficiency gains might well outweigh the small risk of a rogue node
being connected.
>> Can the firewall do anything about this - more of an IDS example?
3.4. Renumbering Attacks
Spurious Renumbering messages can lead to the disruption of a site.
Although Renumbering messages are required to be authenticated with
IPsec, so that it is difficult to carry out such attacks in practice,
they should not be allowed through a firewall.
>> So how do I renumber a network with Router Renumbering where subnets
have their own firewalls? Today a 'firewall' can be applied per port
on a reasonable switch-router unit. Is this document focused on
purely the classic one-firewall-at-site-border model?
Also clarify here you mean Router Renumbering protocol.
(Of course, Router Renumbering protocol has its own issues, but that's
another story)
4.1. Common Considerations
Depending on the classification of the message to be filtered (see
Section 2), ICMPv6 messages should be filtered based on the ICMPv6
type of the message and the type (unicast, multicast, etc.) and scope
(link-local, global unicast, etc) of source and destination
>> Add ULA, though they are now defined as global? Then there's no 'etc'.
Where messages are not essential to the establishment of
communications, local policy can be used to determine whether a
message should be allowed or dropped.
>> Well, the previous section talked in more detail about must/should/etc
than this - this is superfluous?
Depending on the capabilities of the firewall being configured, it
may be possible for the firewall to maintain state about packets that
may result in error messages being returned or about ICMPv6 packets
(e.g., Echo Requests) that are expected to receive a specific
response. This state may allow the firewall to perform more precise
checks based on this state, and to apply limits on the number of
ICMPv6 packets accepted incoming or outgoing as a result of a packet
traveling in the opposite direction. The capabilities of firewalls
to perform such stateful packet inspection vary from model to model,
and it is not assumed that firewalls are uniformly capable in this
respect.
>> RFC4443 talks about ideas for rate-limits for forwarding ICMPv6.
In general, the scopes of source and destination addresses of ICMPv6
messages should be matched, and packets with mismatched addresses
should be dropped if they attempt to transit a router. However some
of the address configuration messages carried locally on a link may
legitimately have mismatched addresses. Node implementations must
accept these messages delivered locally on a link and administrators
should be aware that they can exist.
>> An example?
4.3. Recommendations for ICMPv6 Transit Traffic
This section recommends rules that should be applied to ICMPv6
traffic attempting to transit a firewall.
Davies & Mohacsi Expires January 10, 2007 [Page 12]
Internet-Draft ICMPv6 Filtering Recommendations July 2006
4.3.1. Traffic that Must Not be Dropped
For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be
possible, it is essential that the connectivity checking messages are
allowed through the firewall. It has been common practice in IPv4
networks to drop Echo Request messages in firewalls to minimize the
risk of scanning attacks on the protected network. As discussed in
Section 3.2, the risks from port scanning in an IPv6 network are much
less severe and it is not necessary to filter IPv6 Echo Request
messages.
>> not as necessary?
4.3.5. Traffic which Should be Dropped Unless a Good Case can be Made
Router Renumbering messages should not be forwarded across site
boundaries. As originally specified, these messages may use a site
>> This is better than the text above which said 'must always be firewalled';
it depends where your firewalls are.
scope multicast address or a site local unicast address. They should
be caught by standard rules that are intended to stop any packet with
a multicast site scope or site local destination being forwarded
across a site boundary provided these are correctly configured.
Since site local addresses have now been deprecated it seems likely
that changes may be made to allow the use of unique local addresses
or global unicast addresses. Should this happen, it will be
essential to explicitly filter these messages:
o Router Renumbering (Type 139)
>> So I guess one question is what to recommend for observed use of the now
deprecated old site local prefix?
4.4. Recommendations for ICMPv6 Local Configuration Traffic
This section recommends filtering rules for ICMPv6 traffic addressed
to an interface on a firewall. For a small number of messages, the
desired behavior may differ between interfaces on the site or private
side of the firewall and the those on the public Internet side of the
firewall.
4.4.1. Traffic that Must Not be Dropped
As discussed in Section 4.3.1, dropping connectivity checking
messages will prevent the firewall being the destination of a Teredo
tunnel and it is not considered necessary to disable connectivity
checking in IPv6 networks because port scanning is less of a security
risk.
>> Is a firewall likely to be such a destination?
Link-local multicast receiver notification messages:
o Listener Query (Type 130)
o Listener Report (Type 131)
o Listener Done (Type 132)
o Listener Report v2 (Type 143)
>> I guess for this and for other types you might want to note that whether
you expect to see those types depends on if the interface is point to
point to another router or has hosts on link.
--
Tim/::1