[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
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.
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.
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