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

[Tom Killalea <tomk@nwnet.net>]

Thanks for the prompt feedback Randy.  It's good to see that there's
life on this list.  Comments below.


>>    In the case where one of their connectivity customers appears to be
>>    the source of a security incident an ISP will frequently be
>>    contacted, and in this case they should provide contact information
>>    so that the administrators at the source site can be reached by the 
>>    target site.
>
>Larger ISPs seem unwilling to do this without direction from the police or
>courts, likely because it exposes their customer, with legal ramifications
>for the ISP.

The legal ramifications of anything in this document are hard to pin
down, given that the audience is worldwide.  I know that many in North 
America were surprised by France's 'good samaritan' legislation following 
the Diana/Dodi crash.

>>    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 
>>    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).
>
>Major ISPs with large overloaded aggregation routers seem hesitant to do
>this.  Why?

Inertia, and insufficient pressure from their customers and peers.

>>    Sanctions for running an open mail relay should be covered in an ISP's 
>>    AUP.
>
>Are you suggesting that an ISP should act against a customer who runs an
>open relay?  This is not the way the internet is run today.

Yes, that's what I'm suggesting.  A very short time ago AUPs, and even 
in the case of some ISPs contracts, were unheard of.  It's time to take
the next step.  Too many administrators are unimpressed by the "it's
using up your resources and annoying a lot of people" argument.

>> 5.1 Routers

>>    So access to routers should be as restricted as possible, and strong 
>>    authentication should be used for all connections.
>
>The majority of commonly routers do not yet support strong authentication,
>e.g. kerberos, ssh.
>
>And you do not recommend encryption so sessions can not be stolen?

As you know I'm not a router geek; I admit that this section in
particular could use help.

Anyone care to suggest how I should work in guidelines regarding reuseable
passwords and encryption ?

>>    In any case, SNMPv1 used only trivial
>>    authentication and it's use should be restricted and phased out where
>>    possible.
>
>You're kidding, right.  SNMPv2 is half fielded and provides no significant
>security improvement.  And SNMPv2 is not available on the images used to run
>most of the backbones.

Point taken, I'm rewriting this paragraph.

>> 5.5 Routing Infrastructure
>
>You may want to encourage BGP authentication between peers.  You may want to
>encourage use of authentication when an ISP's IGP supports it.

done.

>
>>    A system should never be placed on a network that will be used for
>>    transit by the ISP's customers.
>
>Ahhhh.  Here it is.  Please remove the "by the ISP's customers."

done.

>>    ISPs commonly operate as secondary (or slave) servers for their
>>    customers, and these servers may provide service for thousands
>>    of zones.  Regardless of the number of zones, administrators of these
>>    servers should be familiar with the Operational Criteria for Root
>>    Name Servers [RFC2010],
>
>I would suggest that they are not running root servers, and hence this
>reference is not useful.

I think the operational criteria for the root servers is good food for 
thought for anyone who is serious about running a big dns server.

>>      - Performance Monitoring.
>>        Key variables such as queries per second and average latency 
>>        should be monitored.
>
>Not for your average ISP.

I've seen a server jump from 50 to 120 queries/sec (sustained for over a
day) due to a single misconfigured customer host.  So apart from the
capacity planning issues I think this is useful.

>And you may want to make folk chosing secondaries aware of 2182.

done.

>> 8.3 Message Submission
>> 
>>    Message submission should be done through the MAIL SUBMIT port (587)
>>    rather than the SMTP port (25) to facilitate the enforcement of
>>    security policy [draft-gellens-submit-05.txt].
>
>Is this realistic?

I'd describe it as optimistic.

>>      - DNS.
>>        DNS lookups should not be performed on web clients when they
>>        connect.
>
>You may wish to explain why.

done.

Also, the Encrypted Transactions paragraph now reads.

     - Encrypted Transactions.
       Transactions should never be stored on the server in unencrypted
       form. Public key cryptography should be used such that only the 
       customer can decrypt the transactions.  Even when transactions
       are passed directly to a financial institution and the customer 
       some part of the transaction will have to be stored by the ISP
       for audit trail purposes.

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