Comments on the old draft

[Rusty Zickefoose <rusty@cw.net>]

Hi all,
	These are notes made on the old draft, it's from a first run
through of possible modifications, and is colored by quite a bit of tunnel
vision (gotta love those mixed metaphors), so I'm not certain how useful
they'll prove.  I'll have more time to devote after the holidays.



2.2 Assistance with Inbound Security Incidents

>>> Rewrite
   When a security incident targeting one of their connectivity
   customers occurs ISPs SHOULD inform the customer of the attack, and
   provide assistance to
>>> Rewrite
<<< 
When an ISP is informed of a security incident targeting one of their
connectivity customers, the ISP SHOULD provide assistance to...
<<<

(or)

<<<
If a security incident targeting one of their connectivity customers
is detected, an ISPs SHOULD inform the customer of the attack, and
provide assistance to
<<<

     - trace the 'apparent' origin of the attack and attempt to
       determine the veracity of each step in the path (keeping in
       mind that the source address may be spoofed).  In cases where
       the source address is spoofed the ISP could trace the point
       at which the bogusly addressed traffic entered the ISP's
       network.

     - obtain contact information for the source of the attack using
       whois [RFC1834 and RFC1835], the DNS [RFC1034 and RFC1035] or
       relevant common mailbox names [RFC2142].

     - collect and protect evidence of the incident and guard against
       its destruction or unintentional announcement.

   If the event continues then, at the customer's request, ISPs may also
   assist by logging in order to further diagnose the problem, or by
   filtering certain types of traffic.


2.3 Assistance with Outbound or Transit Security Incidents

   In the case where one of their connectivity customers appears to be
   the source of a security incident an ISP will frequently be
   contacted.  Once the ISP is satisfied as to the authenticity of the
   report, they should provide contact information so that the
   administrators at the source site can be reached by the target site.

>>> Rewrite
   An ISP may also be contacted to assist with incidents that traverse
   their network but use bogus source addresses, such as SYN flooding
   attacks [CA-96.21.tcp_syn_flooding].  Assistance in this case would
   consist of using network traces on a hop by hop basis to identify the
   point at which the bogusly addressed traffic entered the ISP's
   network.  In tracing such incidents it's frequently necessary to
   coordinating with adjacent ISPs to form a complete chain of response
   teams along the path of the attack.
>>> Rewrite
<<<
   An ISP is frequently contacted when one of their connectivity customers
   appears to be the source of a security incident.  Once the ISP is
   satisfied as to the authenticity of the report, the ISP should deal directly
   with the customer to resolve the security incident.

   An ISP may also be contacted to assist with incidents that traverse
   their network. ISPs should have procedures in place to cooperate
   effectively with adjacent ISPs in order to trace such incidents.
<<<

.
.
.

>>> Section 4.4:  I'm tempted to say that this section is unneccesary, Normal
>>> business practices should dictate such a critical function be performed in
>>> a secure fashion, however...

4.4 Registry Data Maintenance

   ISPs are commonly responsible for maintaining the data that is stored
   in global repositories such as the Internet Routing Registry (IRR)
   and the APNIC, InterNIC and RIPE databases.  Updates to this data
   should only be possible using strong authentication.

5 Network Infrastructure

>>> Rewrite
   ISPs are responsible for managing the network infrastructure of the
   Internet in such a way that it is

     - reasonably resistant to known security vulnerabilities

     - not easily hijacked by attackers for use in subsequent attacks
>>> Rewrite
<<<
ISPs are responsible for managing the network infrastructure of the
Internet in a secure fashion.
<<<

>>> Sections 5.1 - 5.6
>>> Scope: Is this doc directed at ISP engineering?
>>> 
>>> These sections needed to be re-written. They should indicate what level of
>>> security a customer should expect, not how that security is implemented.


5.7 Ingress Filtering on Source Address

   The direction of such filtering is from the edge site (customer) to
   the Internet.

>>> Given the meaning of ``SHOULD'' in RFCs, this paragraph is technically
>>> correct, but its application will be most notable in its absense.

   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].  In addition, forged source addresses are frequently used
   in spoof-based attacks in order to exploit a trust relationship
   between hosts.

   To reduce the incidence of attacks that rely on forged source
   addresses ISPs should do the following.  At the boundary router with
   each of their customers they SHOULD proactively filter all traffic
   coming from the customer that has a source address of something other
   than the addresses that have been assigned to that customer.  For a
   more detailed discussion of this topic see [RFC2267].

>>> Rewrite
   There are (rare) circumstances where ingress filtering is not
   currently possible, for example on large aggregation routers that
   cannot take the additional load of applying packet filters.  In
   addition, such filtering can cause difficulty for mobile users.
   Hence, while the use of this technique to prevent spoofing is
   strongly encouraged, I realise that it is not always feasible.

   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.  In
   general filtering should be done as close to the actual hosts as
   possible.
>>> Rewrite
<<<
   In most circumstances, ingress filtering is not currently possible.
   Large aggregation routers often cannot take the additional load
   of applying packet filters. In addition, such filtering can cause
   difficulty for mobile users or multi-homed customers. Hence, while
   the use of this technique by ISPS is encouraged, it is usually not
   feasible.

   In most cases, the customer should be encouraged to implement ingress
   filtering within their networks. In general filtering should be done
   as close to the actual hosts as possible.
<<<

>>> Section 5.8: This is just plain wrong. Outside of DOS attacks, an ISP
>>> should never discard customer traffic. Decisions of that nature belong,
>>> and should be implemented by, the customer.

5.8 Egress Filtering on Source Address

   The direction of such filtering is from the Internet to the edge site
   (customer).

   There are many applications in widespread use on the Internet today
   that grant trust to other hosts based only on ip address (e.g., the
   Berkeley 'r' commands).  These are susceptible to IP spoofing, as
   described in [CA-95.01.IP.spoofing].  In addition, there are
   vulnerabilities that depend on the misuse of supposedly locally
   addresses, such as 'land' as described in [CA-97.28.Teardrop_Land].

   To reduce the exposure of their customers to attacks that rely on
   forged source addresses ISPs should do the following.  At the
   boundary router with each of their customers they SHOULD proactively
   filter all traffic going to the customer that has a source address of
   any of the addresses that have been assigned to that customer.

   The circumstances described in 5.7 in which ingress filtering isn't
   feasible similarly apply to egress filtering.


5.9 Route Filtering

   Excessive routing updates can be leveraged by an attacker as a base
   load on which to build a Denial of Service attack.  At the very least
   they will result in performance degradation.

   ISPs SHOULD filter the routing announcements they hear, for example
   to ignore routes to addresses allocated for private Internets, to
   avoid bogus routes and to implement route dampening and aggregation
   policy.

   ISPs SHOULD implement techniques that reduce the risk of putting
   excessive load on routing in other parts of the network.  These
   include 'nailed up' routes, aggressive aggregation and route
   dampening, all of which lower the impact on others when your internal
   routing changes in a way that isn't relevant to them.

>>> Section 5.10  Scope again.

5.10 Directed Broadcast

   The IP protocol allows for directed broadcast, the sending of a
   packet across the network to be broadcast on to a specific subnet.
   Very few practical uses for this feature exist, but several different
   security attacks (primarily Denial of Service attacks making use of
   the packet multiplication effect of the broadcast) use it.
   Therefore, routers connected to a broadcast medium SHOULD NOT be
   configured to allow directed broadcasts onto that medium.

   If it is a packet to which the router would respond if received as a
   unicast, it MAY send a (single) response.  If it is not responding
   (either because it's not appropriate, or has been configured not to)
   it MAY send an ICMP error.  It is also appropriate to silently
   discard such packets.  In any case such packets SHOULD be counted to
   detect possible attempts to abuse this feature.

>>>>

Just about everything after this had to do with scope, design vs
expectations.


-- 
Rusty Zickefoose  |  The most exciting phrase to hear in science,
rusty@cw.net      |  the one that heralds new discoveries, is not
                  |  "Eureka!", but "That's funny ..."
                  |  -- Isaac Asimov