Re: draft-ietf-grip-isp-00.txt

[Don Stikvoort <Don.Stikvoort@surfnet.nl>]

==> From: Tom Killalea

Comments like Tom's redirected my attention to the GRIP ISP draft. Ik 
work for an ISP's CERT, so it seems to be my cup of tea.

> To be honest I thought that
> 
>   - the line I took on Source Address Filtering accurately represented
>     discussions that we've had in GRIP meetings, and that I've had
>     privately with some people involved in GRIP

You certainly have my consent. I'll repeat what your draft says:

#4.2 Route Filtering
#
#   Attackers frequently cover their tracks by using forged source 
#   addresses.  To divert attention from their own site the source
#   address they choose will generally be from an innocent remote site or
#   indeed from those addresses that are allocated for private Internets
#   [RFC1918].

Covering their tracks? Why not. But it certainly is used for spoofing 
attacks, which is the other way around: use "trusted" source 
addresses to fool some weakly protected system into opening itself up 
for some protocol - especially useful when you are attacking from the 
OUTSIDE to SOMECOMPANY and you use source addresses from SOMECOMPANY 
to deceive servers of SOMECOMPANY.

This works especially well in the .edu area where firewalls are less 
than common.

Of course all spoofing requires "blind typing" since the reactions go 
back to the source addresses and not to the hacker. So you have to 
know damned well what you are doing - or have script who know damned 
well :-(

There are two ways that help prevent this at the border of a site:
1) to block packets from net to site that use a source address which 
   belongs to the site
2) to block packets from site to net that have a source address which 
   does NOT belong to the site

The first method is fine but does NOT prevent forms of spoofing where
wrong sources OUTSIDE the site's are used in the source address. So 
it's incomplete.

The second method is great but it only works generally if you apply 
it at ALL Internet/intranet borders. So you certainly can't leave it 
to your customers. What we did as an ISP is apply this option to ALL 
our customer connections - this of course leaves one hole and that is 
our connection to the rest of the Net where we can do no checking 
obviously (we could in theory check there if packets come in with 
addresses belonging to our customers, but that would crash the 
routers). 

The more ISPs copying this approach, the smaller the problem. 

Now Mike says that their contracts forbid such filtering. that 
surprises me to no small amount. I wonder about the reason.

So "must" is clearly not usable. I would recommend "should", but if 
necessary "are recommended" could be used instead. Don't leave them 
out however.

#   To prevent attacks that rely on forged source addresses ISPs should 
#   proactively filter at the boundary router with each of their customers 
#   all traffic that has a source address of something other than the 

"all traffic coming FROM the customer that has"

#   addresses that have been assigned to that customer.  (It's
#   regrettable that major router vendors don't make the application of
#   such filters the default behaviour).

Precisely what we (SURFnet) do. Plus we recommend the customer to do 
the type 1 filtering I defined above. This is very neat: we only 
filter what is COMING TO US, and we leave it to the customer what is 
GOING TO THEM.

#   In addition, ISPs should filter and 'black hole' all traffic with
#   source addresses from the address space allocated for private
#   Internets.

What do you mean? If you apply the first rule you just gave this is 
superfluous, isn't it?
Or do you mean filtering ROUTING INFORMATION - that would make sense 
if you apply it to the private address ranges.
 
>   - the line I took on Open Mail Relays wasn't very extreme, where
    extreme is defined as blocking all outbound connections to port 25
>     at the customer's border router except by the customer's known 
>     mail relays.

Clearly an ISP MUST RECOMMEND to its customers to not do open mail 
relaying on their mailservers - actually my CERT-NL issued an 
advisory saying just that recently.

However the ISP itself DOES have a problem in some cases. For 
instance, we offer a mail-fallback service for our customers. With 
the number of customers we have it is not really trivial to prevent open 
relaying there. Some customers may have a problem too, for diverging 
reasons.
"there is no justification" is a trifle too hard I think, in the 
draft.


I hope to have more time to really look into the draft soon :-(

-don