Subject: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt

From: [email-masked]
Date: Mon, 17 Oct 2005 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Best Current Practice for Filtering ICMPv6 Messages in Firewalls
	Author(s)	: E. Davies, J. Mohacsi
	Filename	: draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
	Pages		: 27
	Date		: 2005-10-17
	
   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.  A number of security risks are associated with uncontrolled
   forwarding of ICMPv6 messages.  On the other hand, compared with IPv4
   and the corresponding protocol ICMP, ICMPv6 is essential to the
   functioning of IPv6 rather than a useful auxiliary.

   This document provides some recommendations for ICMPv6 firewall
   filter configuration that will allow propagation of ICMPv6 messages
   that are needed to maintain the functioning of the network but drop
   messages which are potential security risks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 19 Oct 2005 13:32:32 +0100

This new wg draft was published this week.  It is a substantial rewrite 
of the individual draft which Janos and I published in July.

It now covers all the messages that are currently defined for ICMPv6 and 
is written in a format which should make it easier for administrators to 
crate firewall rules from it.

Comments would be appreciated.

One suggestion we had was to include a set of 'pseudo-code' rules as a 
an example of how the recommendations might be implemented.

Regards,
Elwyn

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Oct 2005 18:32:25 +0200

In your previous mail you wrote:

   
=> if you believe I should add a reference to this I-D in the
draft-dupont-mip6-dhaadharmful-01.txt I-D where I've just added
a section about ICMPv6 filtering impact on DHAAD (written by James
Kempf), please send a note to me.

Regards

[email-masked]

PS: my I-D will never be published as it but the ideas/arguments in it
will be in a standard track document (if they are adopted of course),
so the reference too.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 23 Oct 2005 05:51:02 -0300

At 09:32 a.m. 19/10/2005, Elwyn Davies wrote:

>This new wg draft was published this week.  It is a substantial rewrite of 
>the individual draft which Janos and I published in July.
>

A couple of issues that seem to be missing:

* There's no mention of ICMP attacks against TCP. I have authored a draft 
on this issue, along with counter-measures. You can find my internet-draft 
at http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-04.txt 
. You should probably mention the attacks, and provide a reference to my 
draft for further discussion.

* There's no mention of ingress and egress ICMP-filtering based on the 
payload of ICMP messages. You can find a description of such an "advanced" 
filtering in Section 4.3 ("Filtering ICMP error messages based on the ICMP 
payload") of my internet-draft "ICMP attacks against TCP", too.

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 23 Oct 2005 13:09:06 +0100

Hi, Fernando.

Fernando Gont wrote:

>> This new wg draft was published this week.  It is a substantial 
>> rewrite of the individual draft which Janos and I published in July.
>>
>> It now covers all the messages that are currently defined for ICMPv6 
>> and is written in a format which should make it easier for 
>> administrators to crate firewall rules from it.
>>
> * There's no mention of ICMP attacks against TCP. I have authored a 
> draft on this issue, along with counter-measures. You can find my 
> internet-draft at 
> http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-04.txt 
> . You should probably mention the attacks, and provide a reference to 
> my draft for further discussion.
>
> payload of ICMP messages. You can find a description of such an 
> "advanced" filtering in Section 4.3 ("Filtering ICMP error messages 
> based on the ICMP payload") of my internet-draft "ICMP attacks against 
> TCP", too.
>
Denial of service attacks via error messages are covered in s3.1 (I 
believe the attacks covered in your draft fall into this category). 

After your previous message on this subject, I did mention the 
possibility of deep packet inspection looking at the embedded packet 
(s4.1, next to last paragraph) and that this was relevant to the TCP 
attacks you describe.  However, this draft is specifically about 
firewall rules and the firewall would have to do quite heavy work on the 
packet to implement this sort of rule - not all firewalls are 
ncecessarily capable of this.  If the firewall can carry out the checks 
then they shuld apply to error messages for any sort of transport and 
not just TCP.  Also if the embedded packet is encrypted, it would not be 
possible to tell that it was specifically a TCP packet.   On the other 
hand end hosts should certainly do the verification as mentioned in your 
draft as is implied by the words in s4.1.

As regards referencing the draft, I did consider this: it would be 
possible but it would preferable if it was clear that it was going to 
become an RFC.  I notice that the current version of the draft has 
expired... are you making any moves to either have this adopted as a wg 
draft or get it published as an individual submission RFC.  I would 
suggest you talk to either Margaret Wasserman (covering the ipv6 group) 
or David Kessens (v6ops) to see if you can have it published as an 
individual submission via AD since it is pretty much complete and the 
IPv6 wg is currently winding down and maybe reluctant to take on new work.

Regards,
Elwyn

---

From: Fernando Gont <[email-masked]>
Date: Sun, 23 Oct 2005 13:56:12 -0300

>believe the attacks covered in your draft fall into this category).

Yes, but that section basically mentions only blind connection-reset 
attacks. The attacks discussed in my draft can be performed not only 
against TCP, but against similar protocols such as SCTP, too.

>After your previous message on this subject, I did mention the possibility 
>of deep packet inspection looking at the embedded packet (s4.1, next to 
>last paragraph) and that this was relevant to the TCP attacks you describe.

While the draft mentions deep packet inspection, it still does not mention 
ingress and egress filtering based on the IP address contained in the ICMP 
payload. If you receive a packet from your local network, and the IP 
address contained in the ICMP payload claims to be from a network that you 
know you are not connecting to the Internet, you should drop it. Also, if 
you receive a packet from the Internet which contains in the ICMP payload a 
source IP address which belongs to the network you are providing 
connectivity, you should drop it.

This simple policy helps *a* *lot* to prevent ICMP attacks against 
transport protocols such as TCP.

>However, this draft is specifically about firewall rules and the firewall 
>would have to do quite heavy work on the packet to implement this sort of 
>rule - not all firewalls are ncecessarily capable of this.

Note that the firewall needs not keep per-conenction state to perform the 
checks I mentioned.

>If the firewall can carry out the checks then they shuld apply to error 
>messages for any sort of transport and not just TCP.

Correct. But this ingress and egress filtering policy is not TCP-specific, 
but general. Not that it does not require per-connection state, and thus it 
does not require firewalls to be able to parse the transport protocol headers.

>Also if the embedded packet is encrypted, it would not be possible to tell 
>that it was specifically a TCP packet.

Well, you need not know it to filter it.

>become an RFC.

As to whether it is clear it will become an RFC, I hope and think so. 
However, I'm not sure this is relevant. If I submitted the draft directly 
to the RFC Editor to publish it as Informational, the processing backlog 
might be long enough to be certain.

>I notice that the current version of the draft has expired...

No, current version is -05, and has been available since September 5th.

>are you making any moves to either have this adopted as a wg draft or get 
>it published as an individual submission RFC.

Yes, I will be presenting the draft at the next IETF, in the TCPM WG 
meeting. Pekka Savola presented this draft at IETF 62, too.
And this draft has probably been the most discussed draft at the TCPM WG 
mailing list since August 2004.

The draft has even received support from the IAB in their document 
"Architectural Implications of Link Indications" 
(draft-iab-link-indications-03). And is referenced in the current ICMPv6 draft.

>I would suggest you talk to either Margaret Wasserman (covering the ipv6 
>group) or David Kessens (v6ops) to see if you can have it published as an 
>individual submission via AD since it is pretty much complete and the IPv6 
>wg is currently winding down and maybe reluctant to take on new work.

Thanks for your comments. We are still discussing the draft at the TCPM WG, 
and I hope it becomes a WG item in the next IETF.

Not to mention that if your schedule allows you, I'd appreciate if you 
could be present at that meeting. It would certainly help to move things 
forward. We will also be discussing draft-gont-tcpm-tcp-soft-errors-02.txt, 
which originated in this WG (v6ops), and is still being argued against at 
the TCPM WG.

Kindest regards,

---

From: Elwyn Davies <[email-masked]>
Date: Sun, 23 Oct 2005 19:14:24 +0100

> against TCP, but against similar protocols such as SCTP, too.

I am not currently very specific about what DoS attacks can be made.  
The wording is not exclusive and covers any sort of DoS attack that can 
be made with ICMPv6.

It is possible that we should be more comprehensive about the attacks 
that could be made via ICMPv6 but maybe this should be in the security 
overview document rather than here.  That document has been through last 
call but is still just about open for comments.. take a look.

>> attacks you describe.
> While the draft mentions deep packet inspection, it still does not 
> mention ingress and egress filtering based on the IP address contained 
> in the ICMP payload. If you receive a packet from your local network, 
> and the IP address contained in the ICMP payload claims to be from a 
> network that you know you are not connecting to the Internet, you 
> should drop it. Also, if you receive a packet from the Internet which 
> contains in the ICMP payload a source IP address which belongs to the 
> network you are providing connectivity, you should drop it.
>
> transport protocols such as TCP

I appreciate that it will help and I believe we are pointing up the problem.
.
We don't use the words ingress and egress filtering (after all the whole 
of s4.2 is about ingress and egress filtering) but we are saying that if 
your firewall is up to it, it should look at the embedded packet and 
check it has sensible addresses.  Are you saying we should try to do 
more?  If so just what are we to do?  I think the firewall can only do 
more if it is retaining state about packets in the opposite direction 
and not every firewall can do that.

One thing that would perhaps help is to put a pointer in s4.2.1 to the 
additional discussion in s4.1 to remind admins  that *if* your firewall 
can handle it you can go the extra distance..

Regards,
Elwyn

>
>
>
>> However, this draft is specifically about firewall rules and the 
>> firewall would have to do quite heavy work on the packet to implement 
>> this sort of rule - not all firewalls are ncecessarily capable of this.
>
>
> Note that the firewall needs not keep per-conenction state to perform 
> the checks I mentioned.
>
>
>
>> If the firewall can carry out the checks then they shuld apply to 
>> error messages for any sort of transport and not just TCP.
>
>
> Correct. But this ingress and egress filtering policy is not 
> TCP-specific, but general. Not that it does not require per-connection 
> state, and thus it does not require firewalls to be able to parse the 
> transport protocol headers.
>
>
>> Also if the embedded packet is encrypted, it would not be possible to 
>> tell that it was specifically a TCP packet.
>
>
> However, I'm not sure this is relevant. If I submitted the draft 
> directly to the RFC Editor to publish it as Informational, the 
> processing backlog might be long enough to be certain.
>
>
>
>> are you making any moves to either have this adopted as a wg draft or 
>> get it published as an individual submission RFC.
>
>
> And this draft has probably been the most discussed draft at the TCPM 
> WG mailing list since August 2004.
>
>> I would suggest you talk to either Margaret Wasserman (covering the 
>> ipv6 group) or David Kessens (v6ops) to see if you can have it 
>> published as an individual submission via AD since it is pretty much 
>> complete and the IPv6 wg is currently winding down and maybe 
>> reluctant to take on new work.
>
>
> Thanks for your comments. We are still discussing the draft at the 
> TCPM WG, and I hope it becomes a WG item in the next IETF.
>
> could be present at that meeting. It would certainly help to move 
> things forward. We will also be discussing 
> draft-gont-tcpm-tcp-soft-errors-02.txt, which originated in this WG 
> (v6ops), and is still being argued against at the TCPM WG.
>
> Kindest regards,
>
> -- 
> Fernando Gont

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Oct 2005 12:29:55 -0300

At 03:14 p.m. 23/10/2005, Elwyn Davies wrote:

>The wording is not exclusive and covers any sort of DoS attack that can be 
>made with ICMPv6.
>
>It is possible that we should be more comprehensive about the attacks that 
>could be made via ICMPv6 but maybe this should be in the security overview 
>document rather than here.

My feedback was based on the perception that there was a more 
extensive/explicit discussion of redirect attacks, for example.

>That document has been through last call but is still just about open for 
>comments.. take a look.

I will have a look at the security overview document.

>>mention ingress and egress filtering based on the IP address contained in 
>>the ICMP payload. If you receive a packet from your local network, and 
>>the IP address contained in the ICMP payload claims to be from a network 
>>that you know you are not connecting to the Internet, you should drop it. 
>>Also, if you receive a packet from the Internet which contains in the 
>>ICMP payload a source IP address which belongs to the network you are 
>>providing connectivity, you should drop it.
>>
>your firewall is up to it, it should look at the embedded packet and check 
>it has sensible addresses.  Are you saying we should try to do more?  If 
>so just what are we to do?  I think the firewall can only do more if it is 
>retaining state about packets in the opposite direction and not every 
>firewall can do that.

My impression was that you only recommend deep packet inspection as part of 
stateful inspection.

Also, it's not clear to me that the draft proposes to filter those ICMP 
packets whose payloads contain an IP packet with a source address that does 
not correspond to any of the networks to which the router/firewall is 
providing connectivity.

e.g., my faculty's network is 170.210.17.0/24. If the source IP address of 
the payload of an ICMP error message does not correspond to that network, 
the faculty's firewall won't let the ICMP error message go out to the Internet.

That's what I think is missing in your document, or, at least, not very 
explicit.

>can handle it you can go the extra distance..

Note that the check I'm describing does not need the firewall to keep state.

Kindest regards,