[email protected]
[Top] [All Lists]

Comments on draft-ietf-rtgwg-rfc3682bis-05.txt

Subject: Comments on draft-ietf-rtgwg-rfc3682bis-05.txt
From: Alex Zinin
Date: Fri, 20 May 2005 09:34:10 -0700
Dave, et al-

 I've reviewed the draft with the "PS spec" glasses on and have several
 proposed changes.

 Here's the summary:

 1. Spelled out the assumptions about receive-path filtering capabilities
    and resource separation in the routers.

 2. More detailed explanation of the received packet processing, including
    packet classification

 3. Added IP fragment processing

 4. Added handling sessions with parameters not known a priori

 I'd like to encourage people to read through the text below and see if
 there are any objections on what the document say MUST, SHOULD, or MAY
 be done.

--
Alex
 
----

Add as 2.3 in the "Assumptions" section:

A router implementing GTSM for some of its protocol sessions is supposed to
perform the following functions:

  1. Receive-path packet filtering: among the packets destined for its
     control plane, a router is supposed to be able to identify those that
     belong to a specific GTSM-enabled protocol session. This is usually
     done using a set of rules, each specifying such parameters as, source
     and destination IP addresses, protocol number and source and destination
     ports (for UDP or TCP).

     Associated with each filtering entry is also a range of acceptable TTL
     values that is used to decide wether a packet is considered trusted or
     not.
     
     As GSTM-enabled protocol sessions are established and torn down, this
     set of rules is updated.

  2. Resource separation: the router is supposed to use separate resource
     pools (e.g. queues, processing quotas) for the subset of control plane
     packets matching the criteria described above (in other words, packets
     with a higher level of trust) and the packets that do not match those.

Note that this document does not prescribe further restrictions that a
router may apply to the packets not matching the GTSM filtering rules, such
as dropping packets that do not match any configured protocol session and
rate-limiting the rest. This document also does not suggest the actual
means of resource separation, as those are hardware and
implementation-specific.

The possibility of DoS attack prevention, however, is based on the
assumption that packet classification and separation of their paths is done
before they go through a scarce resource in the system. In practice, this
means that, the closer GTSM processing is done to the line-rate hardware,
the more resistant the system is to the DoS attacks.

3. Change the "GTSM procedure" section to:

If GTSM is not built into the protocol and used as an additional feature
(e.g., for BGPv4, or LDP), it SHOULD NOT be enabled by default.

In the procedures described below it is assumed that filtering-related
parameters associated with a session are known at the time of adding an
entry to the GTSM filtering database. For more information on how to handle
situations where session parameters are not known a priori, see section
3.3.

Each session protected with GTSM is associated with a variable TrustRadius
that denotes the distance from the node performing the GTSM check to the
trusted sources of protocol packets. This variable is used to calculate
the range of allowed TTL values used in the filtering entry as follows:

       TTL range = [(255 - TrustRadius)..255]

The reason for using a range of values rather than a single one is that the
actual number of hops that a protocol session between remote peers may
traverse is not constant and will change in time depending on the changes
in network topology. Even in a stable topology, the number of traversed
hops may change for each new session between the peers due to the ECMP
behavior in the network.
       
If GTSM is enabled for a protocol session, an entry is added for
receive-path filtering with corresponding source and destination IP
addresses, protocol number, source and destination ports (for UDP or TCP),
and the calculated TTL range associated with the entry. The following steps
are added to the IP packet sending and reception procedures:

  Sending protocol packets:

    The TTL field in all IP packets used for transmission of messages
    associated with GTSM-enabled protocol sessions MUST be set to 255.

  Receiving protocol packets:

    The GTSM packet identification step described here MUST be applied
    before any protocol-specific or general IP processing is executed on a
    received packet addressed to the router's control plane. This gives the
    router an opportunity to discriminate packets with TTL values outside
    the safe TLL range calculated as described above before any scarce
    resources are spent on more elaborate packet processing, including
    cryptographic authentication.

    The following steps associate each received packet addressed to the
    router's control plane with one of the following three trustworthiness
    categories:

      - Unknown: these are packets that cannot be associated with any
        registered GTSM-enabled session, and hence GTSM cannot make any
        judgement on the level of risk associated with them.

      - Trusted: these are packets that have been identified as belonging
        to one of the GTSM-enabled sessions, and their TTL values are
        within the expected range.

      - Dangerous: these are packets that have been identified as belonging
        to one of the GTSM-enabled sessions, but their TTL values are NOT
        within the expected range, and hence GTSM believes there is a risk
        that the packets have been spoofed.
      
      For every IP packet addressed to the router's control plane, do the
      following:

        1. Locate the filtering entry best matching the packet. The actual
           algorithm for entry lookup is outside of the scope of this
           specification. However, the implementations MUST ensure that
           if more than one entry matches the packet, the more specific
           entry is used.

           For example, if the set of filtering rules has been populated
           with the following entries--

             #  Identification params                 TTL range
             ----------------------------------------------------
             1  {*, 10.1.1.2, TCP, 179, *}            [240..255]
             2  {*, 10.1.1.2, TCP, *, 179}            [240..255]
             3  {10.1.1.1, 10.1.1.2, TCP, 3001, 179}  [255]

           --and a packet with parameters {10.1.1.1, 10.1.1.2, TCP, 3001, 179}
           is received, entry number 3 should be returned.

        2. If no matching entry was found, the packet is packet is
           classified as Unknown.

        3. Otherwise, if the value of the TTL field in the packet is within
           the TTL range associated with the filtering entry, the packet is
           classified as Trusted.

        4. Otherwise (the packet's TTL value is outside the entry's range),
           the packet is classified as Dangerous.

        Note that the above algorithm cannot be abbreviated by including
        the TTL range in the set of identification (matching) parameters.
        Doing so would make it impossible to distinguish packets that
        belong to non-GTSM sessions and packets that fail the TTL check.

The exact policies applied to packets of different classifications are not
postulated in this document and are expected to be configurable.

However, by default, the implementations:

  o SHOULD ensure that packets classified as Dangerous do not compete for
    resources with packets classified as Trusted or Unknown.

  o MUST NOT drop (as part of GTSM processing) packets classified as
    Trusted or Unknown.

  o MAY drop packets classified as Dangerous.

If GTSM is applied to a protocol session that is expected to always run
between directly connected peers, the value of TrustRadius SHOULD be set to
zero, thus limiting the TTL range to a single value of 255.

The value of TrustRadius for non-direct protocol sessions is not specified
in this document and SHOULD be configurable.

3.2 Dealing with IP fragments

Depending on the type of the protocol session, being protected with GTSM,
it may or may not be possible to identify the protocol session that a
received IP fragment belongs to. For example, if the fragment contains part
of an OSPF link-state update packet, the IP header will have sufficient
information to identify the OSPF adjacency being protected. However, if the
fragment contains part of a TCP segment, the implementation may have no way
to tell which TCP session it belongs until the fragment is processed by the
IP module.

Routers are expected to be configurable with the policies applied to the
fragments that can't be associated with a GTSM-protected protocol session.
(As an example, the administrator may want to classify any unidentified
fragments from a subset of IP address as Dangerous and unidentified
fragments from all other addresses as Unknown.) However:

  o Such unidentified fragments SHOULD NOT be classified as Trusted

  o Such unidentified fragments SHOULD NOT be dropped (as part of GTSM
    operation) by default.

3.3 Protecting sessions with dynamic parameters

In certain situations, it is impossible to tell the exact IP parameters of
a protocol session until several IP packets associated with it have been
exchanged by the peers, however it is still desirable to protect those
initial packets with GTSM as well.

As an example, BGP peers A and B generally cannot tell the parameters of
the TCP connection they are finally going to use for the BGP session
because:
  a) Any side can initiate the TCP connection and win it, AND
  b) If the remote side's TCP connection is used, its TCP port is not
     known a priori.

In situations like this, implementations can use temporary less specific
filtering entries before the exact parameters of the session are known and
replace them with the more specific entry as soon as the specifics have
been learned.

In the example with a BGP sessions between A and B above, A could use the
following approach (assuming peers are directly connected):

  1. Before the actual TCP session has been established, install the
     following two filtering entries:

             #  Identification params                 TTL range
             ----------------------------------------------------
             1  {B, A, TCP, BGP, *}                   [255]
             2  {B, A, TCP, *, BGP}                   [255]

  2. As soon as the TCP connection is established, the two entries above
     are replaced with a more specific entry constructed using the
     connection parameters. For example:

             #  Identification params                 TTL range
             ----------------------------------------------------
             1  {B, A, TCP, BGP, 3001}                [255]

----


_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

<Prev in Thread] Current Thread [Next in Thread>