[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on ISP Expectations
- To: grip-wg@TransSys.COM
- Subject: Comments on ISP Expectations
- From: Bill Woodcock <firstname.lastname@example.org>
- Date: Wed, 29 Mar 2000 19:37:07 -0800 (PST)
- Comment: grip-wg mailing list add/drop requests to Majordomo@TransSys.COM
> 1 Introduction
> We do not include in our definition of an ISP organisations
> providing those services for their own purposes.
Our definition does not include organizations which provide these
services internally or to their own parent organization.
> 2 Communication
> The community's most significant security-related expectations of
> ISPs relate to the availability of communication channels for dealing
> with security incidents.
...availability, accessibility, and security of communication...
> 2.2 Information Sharing
> ISPs SHOULD have clear policies and procedures on the sharing of
> information about a security incident
...clear public policies...
> 2.3 Secure Channels
For the purposes of this document, "secure" means reasonably protected
against eavesdropping or impersonation.
> 4.1 Registry Data Maintenance
> ISPs should 'SWIP' (Shared WhoIs Project) the address space that
> they assign to their customers
...or maintain an rwhois server within the rwhois delegation tree.
> 4.2 Routing Infrastructure
> An ISP's ability to route traffic to the correct destination
> depends on routing policy as configured in the routing registries
Not in very many cases. Good to keep it synchronized, though.
> BGP authentication should be used with routing peers.
Nobody does this in the real world.
> 4.3 Ingress Filtering on Source Address
> such filtering can cause difficulty for mobile users.
> In these rare cases where ingress filtering at the interface between
> the customer and the ISP is not possible, the customer should be
> encouraged to implement ingress filtering within their networks.
Egress, not ingress.
> 4.4 Egress Filtering on Source Address
Subnet-broadcast addresses should also be filtered.
> 5 Systems Infrastructure
Systems MUST minimally be separated by a switched LAN infrastructure, such
that compromise of one host does not allow promiscuous "sniffing" of
to and from other hosts, and SHOULD be separated onto separate VLANs or
subnets, such that traffic can be filtered both to and from each system,
without the possibility of a "stepping stone" attack from one host to
"behind" a firewall.