Comments on draft-zhao-opsec-routing-capabilities-02.txt

["George Jones" <eludom@gmail.com>]

Search for "gmj>" below.


---George Jones

OPSEC Working Group                                           Zhao Ye
Internet Draft                                             Miao Fuyou
Expires: November 2006                             Huawei Technologies
                                                             R. Callon
                                                      Juniper Networks
                                                        June 29, 2006



               Routing Control Plane Security Capabilities
              draft-zhao-opsec-routing-capabilities-02.txt

Conventions used in this document

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119]

...
gmj> This is redundant.  Section 1.4 contains this informatoin. Delete
this section.
...

1.2. Capabilities versus Requirements

  Capabilities may or may not be requirements. That is a local
  determination that must be made by each operator with reference to
  the policies that they must support. It is hoped that this document,
  together with [OSCP] will assist operators in identifying their
  security capability requirements and communicating them clearly to
  vendors.

...
gmj> We need a standard text for this section to be used in all
capability drafts.
gmj> I will work on this.
...

  The capabilities described in this document follow the format
  outlined in section 1.7 of [FRAMEWORK].

1.3. Packet Filtering versus Route Filtering

..
  packets which might be part of the same stream (and thus which may
  also be forwarded by the same router). One commonly minor exception

gmj> s/commonly// (delete the word)

  to the "stateless" nature of packet filters is that packets that fit

gmj> s/fit/match/ (replace word)

...

gmj> Very nice discussion.

1.4. RFC 2119 Keywords

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].



Zhao                  Expires December 29, 2006               [Page 4]

Internet-Draft   Control Plane Security Capabilities         June 2006


  The use of the RFC 2119 keywords is an attempt, by the authors, to
  assign the correct requirement levels ("MUST", "SHOULD", "MAY"...).
  It must be noted that different organizations, operational
  environments, policies and legal environments will generate different
  requirement levels.

  NOTE: This document defines capabilities. This document does not
  define requirements, and there is no requirement that any particular
  capability be implemented or deployed. The use of the terms MUST,
  SHOULD, and so on are in the context of each capability in the sense
  that if you conform to any particular capability then you MUST or
  SHOULD do what is specified for that capability, but there is no
  requirement that you actually do conform to any particular capability.

gmj> again, I will work up some standard text for this part of all the
capabilities docs.

2. Route Filtering Capabilities

2.1. Route Filtering of External Routing Protocols

  Capability.
  The device MUST provide a means to filter routing updates for all

Minor formatting issue...looks better if you do something like:

"   Capability

     The device provides..."

Note the spacing and indentatoin.   xml2rfc handles this for you.
Same issue with all subsections.


gmj> s/MUST provide/provides/ Change MUSTs to simple assertions.
gmj> Same issue throughout the document.

  protocols used to exchange external routing information. Generally
  this includes BGP [RFC4271], as well as static routes.

  Supported Practices.
  See [RFC3013] and section 3.2 of [RFC2196] and section 2.5 of [OSCP].

  Current Implementations.
  Typically BGP implementations allow operators to apply a variety of
  filters to restrict which incoming updates are accepted from BGP
  peers, as well as to limit which updates are sent out to BGP peers.
  In general packet filters may be used in the following ways:

gmj> s/packet/route/

  - Routers MUST allow operators to configure route filters which
  restrict which routes are accepted from other peer routers. Route
  filters MUST be capable of being individually configured on a per-
  neighbor basis.

gmj> remove the MUSTs.  Break this into two items.   Possibly break
gmj> each one of these items out into it's own capability (e.g. 1. why
gmj> do you want to be able to resrict route updates 2. why is it important
gmj> to do it on a per-neighbor basis ?

  - Routers MUST allow operators to configure route filters which
  restrict which routes are sent to other peer routers. Route filters
  MUST be capable of being individually configured on a per-neighbor
  basis.

  - Routers SHOULD allow operators to configure whether Outbound Route
  Filters [ORF] are accepted from other peer routers. This SHOULD be
  configurable on a per-neighbor basis.




Zhao                  Expires December 29, 2006               [Page 5]

Internet-Draft   Control Plane Security Capabilities         June 2006


  - Routers SHOULD allow operators to configure which (if any) Outbound
  Route Filters [ORF] are sent to other peer routers. This SHOULD be
  configurable on a per-neighbor basis.

  In general route filters determine whether a route is accepted from
  or sent to a neighboring router. Filters MAY be based upon any
  combination of route attributes, such as:

     - Specific route prefixes

     This may include a list of specific prefixes to be accepted or
     rejected. This may alternately include a list of prefixes, such
     that more specific (longer) prefixes which are included in the
     more inclusive (shorter) prefix are accepted, rejected, or
     summarized into the shorter prefix.

     - Maximum length of route prefix

     - Maximum number of routes to be accepted from a particular peer
     router

     If too many routes are received, then the router may reset the
     BGP session, or may reject excess routes. In either case the
     failure event should be logged.

gmj> These need to be split out.  Resetting an overactive session may be good
gmj> (why ?).  Logging falures may be good (why ?).  They are separate
capabilities.

     - Restrictions on the AS_PATH

     Restrictions on the contents of the AS PATH are frequently used:
     for example if you get a prefix from AS X, then you might want to
     make sure that X is in the AS PATH.


     - Restrictions on BGP Community and Extended Community



  Route redistribution is used to exchange routing information between
  different protocols. Although route redistribution bridges between
  different route domains and improves the flexibility of routing
  system, it may lead to looping or black hole as well.

gmj> this (preventing loops) looks like the supported practice
gmj> for the capability defined below.

  - Routers SHOULD provide method to limit the scope of route
  redistribution between different route protocols. Unfiltered
  redistribution SHOULD be forbidden.





Zhao                  Expires December 29, 2006               [Page 6]

Internet-Draft   Control Plane Security Capabilities         June 2006


  Considerations.
  Operators may wish to ignore advertisements for routes to specially
  used addresses, such as private addresses, reserved addresses and

gmj> s/specifically used/specific/

  multicast addresses, etc. The up-to-date allocation of IPv4 address
  space can be found in [IANA].

...
  2.2.2. Route Filtering Between IGP Areas

  Capability
  It is normal when passing routes into the backbone area (area O.0.0.0
  in OSPF, or the level 2 backbone in IS-IS) for routes to be
  summarized, in the sense that multiple more specific (longer) address
  prefixes that are reachable in an area may be summarized into a
  smaller number of less specific (shorter) address prefixes. This
  provides important scaling improvements, but is generally not
  primarily intended to aid in security and is therefore outside of the
  scope of this document.


gmj> Again, it looks like you listed the supported practice (above)
gmj> and the capability (below).

  Routers MAY implement the capability to allow the network operator
  the option of configuring route filters which restrict which routes
  (i.e. address prefixes) are advertised into areas from outside of the
  area (i.e. from other OSPF or IS-IS areas).

  Supported Practices
  TBD.

  Current Implementations
  TBD.



Zhao                  Expires December 29, 2006               [Page 7]

Internet-Draft   Control Plane Security Capabilities         June 2006


  Considerations
  If filters are used which restrict the passing of routes between IGP
  areas, then this may result in some addresses being unreachable from
  some other areas within the same routing domain.

2.3. Ability to Filter Routing Update by TTL

  Capability
  The device should provide a means to filter route packets based on

s/should provide/provides/

  the value of the TTL field in the IPv4 header or the Hop-Limit field
  in the IPv6 header.

gmj> The preceeding looks like a capability.   The following looks like
gmj> a supported practice.
gmj>
gmj> Also, you should cite 3682 here.   You list it in your references.
gmj> As a general rule, if you have something listed in your references
gmj> it should be cited in the body of the document (I think the RFC editor
gmj> may enforce this before publication).
gmj>
gmj> This whole section looks like good material...it just needs to be
gmj> re-arranged a bit.

  For example, in many cases routing protocol packets should only be
  arriving from immediate neighboring routers. In these cases, packets
  SHOULD be dropped if the TTL is not equal to 255. In these cases
  filtering on TTL prevents any system which is not immediately
  physically adjacent to a router from sending that router spoofed
  routing packets.



  Note that "Filtering Capabilities for IP Network Infrastructure"
  [FILTER] specifies:

      Capability.

      The filtering mechanism supports filtering based on the value(s)
      of any portion of the protocol headers for IP, ICMP, UDP and TCP.

  The ability to filter based on TTL is therefore a packet filtering
  capability which is already implicitly covered by the capabilities
  listed in [FILTER]. Since this capability is particularly important
  for routing protocols, we felt that it is worth mentioning here.

  Supported Practices.
  See [OSCP] section 2.5.7

  Current Implementations.
  When a router forwards a packet, it will decrement the TTL value
  (Hop-Limit for IPv6) of the packet by one. Thus, TTL spoofing is
  considered nearly impossible. Furthermore, the vast majority of
  routing peers are adjacent. This capability is therefore quite useful,
  and is widely implemented in routers.

  Considerations.
  There will be situations in which the distance to the neighboring
  router is more than one hop away. This for example is common for I-
  BGP.



Zhao                  Expires December 29, 2006               [Page 8]

Internet-Draft   Control Plane Security Capabilities         June 2006


3. Route Flap Dampening

  "Route flap" means that a route's state changes from up to down or
  down to up. In some cases a route may come up and go down multiple
  times in a short period of time (for example due to an unstable link
  somewhere in the global Internet). When repeated route flapping
  occurs, the route process has to insert or delete an item and the
  advertised update. If large amounts of routes continue to go up and
  down multiple times in a short time period this may result in
  significant load on CPUs and could result in DoS (whether intentional
  or not).

  Capabilities.
  The device MUST provide ability to dampen route flap.

  Route Flap dampening MUST be configurable. For example, some
  operators may want to change the timers, and others may want to turn
  it off altogether.

  Supported Practices.
  The function to dampen route flap may enhance the stability of
  routing system and minimize the influence of flapping. It is useful
  to counter against some DoS attacks.

  Current Implementations.
  In BGP, route flapping dampening is the primary mechanism to mitigate
  the influence caused by flapping. Most of current implements support
  this capability.

  Consideration.

  None

gmj> Good.  I might split into two.   Dampening and configuration.
gmj> Also, this leaves open the question of "what is configurable" ?
gmj> You might want to adddress that.

4. Authentication of Routing Protocols

  As mentioned in [RFC4272], the authentication mechanism specified in
  [TCPMD5] can counter several types of attacks on BGP, such as message
  insertion, modification, deletion, man-in-the-middle, and some types
  of DOS attack. Even though an assailant can guess TCP sequence
  numbers of a BGP session, he will fail to launch the attack mentioned
  above. Most other routing protocols adopt similar authentication
  mechanism.

  Capabilities.
  - MUST provide a mechanism through which operators can manually
  configure a sequence of keys on peer systems


gmj> might want to mention in the consideratoins section that
gmj> manual configuration of keys becomes a scaleing issue.



Zhao                  Expires December 29, 2006               [Page 9]

Internet-Draft   Control Plane Security Capabilities         June 2006


  - MUST provide a mechanism through which peer systems can transition
  from one key to another based upon system time

  - MUST provide a mechanism through which peer systems can transition
  from one key to another without resetting the neighboring session

  - MUST support authentication algorithms that are stronger than MD5
  (e.g., CMAC-AES-128-96, HMAC-SHA-1-96).

gmj> I believe the IETF issued guidance on this (Russ Housley or Steve
Bellovin listening ?).

  - SHOULD support automatic generation and encrypted distribution of
  key material.

  Supported Practices.
  See [OSCP] section 2.5.7.

  Current Implementations.
  [TCPMD5] is deployed widely in BGP. Other routing protocols, such as
  OSPF, adopt similar technology.

  In most of current implements, neither the authentication mechanism
  nor key can be negotiated. An operator has to configure it manually.

  Consideration.
  OSPF supports plain text authentication which is not able to counter
  attacks above. Most OSPF implementations also support MD5
  authentication. In this section the authentication mechanism refers
  to the technology using cryptographic hash functions.

  In order to counter key-guessing attack, when manual key management
  is used, a device SHOULD support a proper length of a key .

gmj> what is proper length ?   How do you define it ?

gmj> this is good, but, gain, it has lots of capabilities rolled into one.
gmj> Needs to be split out some.

...