RE: Digital Island sponsors DoS attempt?

Mailman List Mirror (Read Only)
1

The answer is yes, that's what I'm saying. PMTU is fine on a LAN that could
be capable of Jumbo Frames, but is pretty much useless over the WAN or
internet since the PMTU has to use the lowest comon denominator MTU in the
path. Nobody I know, nor have I ever had a problem with "PMTU" and shutting
off ICMP routing. And no I do not believe it is used across the internet,
and if it does, it is probably hindering performance since it's probably
using a lower mtu than is allowed, such as 576 or smaller. It would also
have problems running across multi-level routing hierarchies.

No, there is a greater need for ICMP drops, and that is ping attacks. Still
happening to some of our customers. No one's going to sit there and filter
IP blocks. There are currently no viable uses or reasons for pinging into
private networks, except for possible troubleshooting, in which case the
admin would be involved.

Finally, I do not believe PMTU uses pings to discover the PMTU. I believe it
uses TCP or UDP packets at the layers above IP, and it DOES use "ICMP Packet
Too big" responses (from the receiver) to cut it's packet size. So in
reality, a router blocking ICMP from being routed through can still send
these ICMP messages PMTU needs. Is this how you understand it?

Marc

2

Don't forget that routers or hosts beyond (from the point of view of the
host attempting PMTU) your ICMP-blocking router may have smaller MTUs than
the norm and may be trying to send ICMP errors back...

3

path. Nobody I know, nor have I ever had a problem with "PMTU" and shutting
off ICMP routing. And no I do not believe it is used across the internet,

Some of us *have* seen it.

and if it does, it is probably hindering performance since it's probably
using a lower mtu than is allowed, such as 576 or smaller. It would also
have problems running across multi-level routing hierarchies.

You have this backwards. RFC791, section 2.1, says:

    impractical for most hosts and networks. All hosts must be prepared
    to accept datagrams of up to 576 octets (whether they arrive whole
    or in fragments). It is recommended that hosts only send datagrams
    larger than 576 octets if they have assurance that the destination
    is prepared to accept the larger datagrams.

    The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information. For
    example, this size allows a data block of 512 octets plus 64 header
    octets to fit in a datagram. The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

So if you're on a LAN that the MTU is 1500, you can be reasonably sure that
the other end can catch 1500 byte packets. If you're *leaving* the subnet,
you have only send 576-byte packets unless you have reason to believe you
can send bigger (PMTU discovery). Some sites just blindly send 1500 bytes
anyhow, and *hope* that things get fragmented - but *THAT* behavior is actually
against-standard.

So the two most prevalent ways to cut the number of packets by 65% or so
are to use PMTUd, or to blindly throw 1500 and hope it works.....

Finally, I do not believe PMTU uses pings to discover the PMTU. I believe it
uses TCP or UDP packets at the layers above IP, and it DOES use "ICMP Packet

RFC1191 is silent on HOW to do it. IBM specifically chose to use ICMP ECHO
to test, rather than the TCP packets, so that PMTU discovery could be
done *before* it might actually be needed (since many TCP applications such
as SMTP and HTTP don't send a full MTU-sized packet right off the bat because
the first few packets are doing negotiation - if you can do PMTU discovery in
parallel with that, it can be a win - if you hit a 'frag needed' only after
several packets, you get to flush the slow-start timers, retransmit, and a lot
of other ugliness....

4

The answer is yes, that's what I'm saying. PMTU is fine on a LAN that could
be capable of Jumbo Frames, but is pretty much useless over the WAN or
internet since the PMTU has to use the lowest comon denominator MTU in the
path. Nobody I know, nor have I ever had a problem with "PMTU" and shutting
off ICMP routing. And no I do not believe it is used across the internet,
and if it does, it is probably hindering performance since it's probably
using a lower mtu than is allowed, such as 576 or smaller. It would also
have problems running across multi-level routing hierarchies.

(I'll make the assumption here that PMTU really means PMTU-D in some
cases)

Using the lowest common denominator MTU in the path is exactly the
point, and it's pretty hard to find out what that value is with PMTU-D.
It *is* used across the internet, and while the MTU usually gets
affected nearer to the edge than the core (PPPoE or other reasons),
various forms of tunneling in the path can drop it below 1500 bytes.
Also, I'd be interested in hearing any facts you might be able to
present on why it would have any problem running across multi-level
routing hierarchies, as I can't possibly see how the choice of routing
protocol or hierarchy would affect the path MTU in the least.

No, there is a greater need for ICMP drops, and that is ping attacks. Still
happening to some of our customers. No one's going to sit there and filter
IP blocks. There are currently no viable uses or reasons for pinging into
private networks, except for possible troubleshooting, in which case the
admin would be involved.

So, your ACLs can determine whether it's an admin or a user sending
ICMP. That's an interesting piece of hardware you have there...

And I don't know about everyone else, but if your network were truly
'private', I wouldn't be able to ping into it anyhow. As soon as you
have users, connect to the internet, and expect to be able to reach the
internet in a mostly unrestricted manner, your network doesn't fit my
definition of 'private'.