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

[Tom Killalea <tomk@nwnet.net>]

Thanks for the comments Don.

>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. 

I think it's worth emphasising that even a partial success is progress,
as it diminishes the networks from which attacks that depend on spoofing
can originate.  Phil is correct in pointing out that tunnelling will
bypass this (and lots of other types of) policy, Randy makes a good
point that fully loaded routers may have a problem coping with any
access lists, while if I can get anything from Mike's comments it's that
contracts are a matter between the ISP and the customer.  No argument.

>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.

Agreed.

>#   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.

Filter at your peerings, and black-hole in your Internal routing (even
if that's redundant).  Again, I'm *not* a routing geek.

>>   - 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.

It's possible to provide mail-fallback service in a manageable way
without leaving your servers open to all.

I certainly intend to tone down the wording there.

Tom.
--
Tom Killalea   (425) 649-7417    NorthWestNet
               tomk@nwnet.net