[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 03:14 p.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.
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.
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.
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.
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..
Note that the check I'm describing does not need the firewall to keep state.
Kindest regards,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org