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

[Randy Bush <randy@psg.com>]

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

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

>    There is no justification for any mail relay on the Internet being left
>    completely open

Seems a pretty absolutist statement.  Too early to think of counterexamples,
but I am sure someone can.

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

> 5.1 Routers

What happened to a bit about not putting hosts on transit sniffable media?
This has been the most seriously exploited vulnerability.

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

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

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

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

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

>      - Recursion should be disabled for queries.  
> 
>      - Zone transfer should be restricted.
>        Apart from the significant load presented by zone transfer 
>        with resultant exposure to Denial of Service attacks, ISPs 
>        should recognise that some of their customers will consider the 
>        contents of their zone files to be private.

These are useful.

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

Not for your average ISP.

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

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

>      - DNS.
>        DNS lookups should not be performed on web clients when they
>        connect.

You may wish to explain why.

>      - Encrypted Transactions.
>        Transactions should never be stored on the server in unencrypted
>        form.  Ideally they should be passed directly to the financial
>        institution and customer without being stored on the server at
>        all

Uh, I suspect that there is a responsibility for auditability which this
violates.

randy