What do you want your ISP to block today?

Owen DeLong owen at delong.com
Sat Aug 30 16:54:12 UTC 2003


> Christopher L. Morrow's mention of asymmetric routing for multihomed
> customers is more to the point, but if we can solve this for all those
> single homed dial, cable and ADSL end-users and not for multihomed
> networks, I'll be very happy.
>
Sorry to throw yet another insect into the topical remedy (fly in the
ointment), but, I happen to look alot like a single homed ADSL end
user at certain levels, but, I'm multihomed.  I'd be very annoyed if
my ISP started blocking things just because my traffic pattern didn't
look like what they expect from a single homed customer.

> So which do you prefer: nobody gets to scan your systems from the outside
> (including you) or everyone gets to scan your systems from the outside
> (including you).
>
I prefer the latter.

>> If you want to know how TCP is working to a destination, you
>> have to use TCP to test it.
>
> As I mentioned above: this will not impact TCP at all because TCP
> generates return traffic. I'm sure there are one or two UDP applications
> out there that don't generate return traffic, but I don't know any. The
> only problem (except asymmetric routing when multihomed) would be
> tunnels, but you can simply enable RIP or something else on the tunnel to
> make sure it's used in both directions. Multicast doesn't generate return
> traffic so this would only apply to unicast destinations.
>
But, TCP to a port that isn't listening (or several ports that aren't
listening) _ARE_ what you are talking about blocking.  This is not a
good idea.

>> Scans by themselves certainly aren't inherently dangerous.
>
> It should be possible to have a host generate special "return traffic"
> that makes sure that stuff that would otherwise be blocked is allowed
> through.
>
I don't think it's desirable or appropriate to have everyone re-engineer
their hosts to allow monitoring and external validation scans to get
around your scheme for turning off services ISPs should be providing.

Owen




More information about the NANOG mailing list