[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Fernando Gont wrote:


At 09:09 a.m. 23/10/2005, Elwyn Davies wrote:
Denial of service attacks via error messages are covered in s3.1 (I 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.
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.
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 

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. 


Well, you need not know it to filter it.
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.
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,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org