Re: Comments on draft-ietf-rtgwg-rfc3682bis-02.txt

[David Meyer <[e-mail]>]

On Mon, Sep 13, 2004 at 05:20:16PM -0700, Alex Zinin wrote:
>> Dave, et al-
>> 
>>  Please find below my comments on draft-ietf-rtgwg-rfc3682bis-02.txt with
>>  the STD glasses on. Use of fixed-size font is recommended.


	Alex,

	What do you mean by fixed-sized font? 

	Dave


>> 
>> -- 
>> Alex
>> http://www.psg.com/~zinin
>> 
>> 
>> > INTERNET-DRAFT                                       V. Gill
>> > draft-ietf-rtgwg-rfc3682bis-02.txt                J. Heasley
>> >                                                     D. Meyer
>> > Category                                        Experimental
>>                                                   ^^^^^^^^^^^^
>>                                             Proposed Standard
>> 
>> Also add:
>> 
>>  Updates: RFC 3682
>>                                                   
>> > Expires: October 2004                             April 2004
>> > 
>> >              The Generalized TTL Security Mechanism (GTSM)
>> >                   <draft-ietf-rtgwg-rfc3682bis-02.txt>
>> > 
>> > 
>> > 
>> > 
>> > Status of this Memo
>> > 
>> > 
>> >    This document is an Internet-Draft and is subject to all provisions
>> >    of Section 10 of RFC2026.
>> 
>> Use the new headers please.
>> 
>> ...
>> 
>> >    This document is a product of the RTG WG WG.  Comments should be
>>                                        ^^^^^^^^^
>>                                        "RTGWG WG"
>> 
>> >    addressed to the authors, or the mailing list at [e-mail].
>> ...
>> > Abstract
>> > 
>> >    The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6)
>> >    to protect a protocol stack from CPU-utilization based attacks has
>> >    been proposed in many settings (see for example, RFC 2461). This
>> >    document generalizes these techniques for use by other protocols such
>> >    as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),
>> >    Bidirectional Forwarding Detection, and Label Distribution Protocol
>> >    (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM)
>> >    is most effective in protecting directly connected protocol peers, it
>> >    can also provide a lower level of protection to multi-hop sessions.
>> >    GTSM is not directly applicable to protocols employing flooding
>> >    mechanisms (e.g., multicast), and use of multi-hop GTSM should be
>> >    considered on a case-by-case basis.
>> 
>> Please add:
>> 
>>  This document updates RFC 3682.
>> 
>> ...
>> 
>> > 1.  Introduction
>> > 
>> >    The Generalized TTL Security Mechanism (GTSM) is designed to protect
>> >    a router's TCP/IP based control plane from CPU-utilization based
>> >    attacks.  In particular, while cryptographic techniques can protect
>> >    the router-based infrastructure (e.g., BGP [RFC1771], [RFC1772]) from
>> >    a wide variety of attacks, many attacks based on CPU overload can be
>> >    prevented by the simple mechanism described in this document.  Note
>> >    that the same technique protects against other scarce-resource
>> >    attacks involving a router's CPU, such as attacks against processor-
>> >    line card bandwidth.
>> > 
>> >    GTSM is based on the fact that the vast majority of protocol peerings
>> >    are established between routers that are adjacent [PEERING]. Thus
>> >    most protocol peerings are either directly between connected
>> >    interfaces or at the worst case, are between loopback and loopback,
>> >    with static routes to loopbacks. Since TTL spoofing is considered
>> >    nearly impossible, a mechanism based on an expected TTL value can
>> >    provide a simple and reasonably robust defense from infrastructure
>> >    attacks based on forged protocol packets.
>>                                              ^
>>                          "from outside the network"
>> 
>> Based on the discussion in the IESG, I would also add something along
>> these lines here:
>> 
>>     GTSM is not a substitute for authentication mechanisms. In particular,
>>     it does not secure against insider on-the-wire attacks, such as packet
>>     spoofing or replay.
>> 
>> > 2.1.  GTSM Negotiation
>> 
>> When GTSM was considered kind of an add-on feature for existing protocols, this
>> section was quite easy--manual configuration is required. However, if we imagine
>> a situation where a new protocol is designed and GTSM support is required, it
>> gets a little more tricky. Please see inline below for suggestions.
>> 
>> >    This document assumes that GTSM will be manually configured between
>>                                ^
>>                  ", when used with existing protocols,"
>>                  
>> >    protocol peers. That is, no automatic GTSM capability negotiation,
>> >    such as is envisioned by RFC 2842 [RFC2842] is assumed or defined.
>> 
>>      If a new protocol is designed with built-in GTSM support, then it is
>>      recommended that procedures are always used for sending and validating
>>      received protocol packets (GTSM is always on, see for example [RFC2461]).
>>      If, however, dynamic negotiation of GTSM support is necessary, protocol
>>      messages used for such negotiation MUST be authenticated using other
>>      security mechanisms to prevent DoS attacks.
>> 
>>      Also note that this specification does not offer a generic GTSM capability
>>      negotiation mechanism, so messages of the protocol augmented with the GTSM
>>      behavior will need to be used if dynamic negotiation is deemed necessary.
>> 
>> ...
>> 
>> > 3.  GTSM Procedure
>> 
>> >    GTSM SHOULD NOT be enabled by default.
>> 
>> This was true before. Since we envision this spec to be also used for
>> new protocols, how about we change this 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.
>> 
>> > The following process
>> >    describes the per-peer behavior:
>> >
>> >     (i)   If GTSM is enabled, an implementation performs the
>> >           following procedure:
>> > 
>> >           (a)  For directly connected routers,
>> > 
>> >                o Set the outbound TTL for the protocol connection to
>> >                  255.
>> > 
>> >                o For each configured protocol peer:
>> > 
>> >                  Update the receive path Access Control List (ACL)
>> >                  or firewall to only allow protocol packets to pass
>> >                  onto the Route Processor (RP) that have the correct
>> >                  <source, destination, TTL> tuple. The TTL must
>> >                  either be 255 (for a directly connected peer), or
>> > 
>> > 
>> > 
>> > Gill, et al.                                        Section 3.  [Page 5]
>> > 
>> > INTERNET-DRAFT            Expires: October 2004               April 2004
>> > 
>> > 
>> >                  255-(configured-range-of-acceptable-hops)
>> >                  for a multi-hop peer. We specify a range here to
>> >                  achieve some robustness to changes in topology. Any
>> >                  directly connected check MUST be disabled for such
>>                    ^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> What is this?
>>                    
>> >                  peerings.
>> 
>> a couple more comments here.
>> 
>>  1. I am not sure if 255-(configured-range-of-acceptable-hops) denotes
>>     a range (as the sentence starting with "We specify" says) or a value
>>     calculated as 255-x. I think the TTL check can be generalized as
>>     follows:
>> 
>>       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. TTL value in a received packet is
>>       considered valid if it is not less than (255 - TrustRadius). Consequently,
>>       if TrustRadius is set to zero for a particular session, only packets from
>>       directly connected neighbors (TTL=255) will be considered valid.
>>       TrustRadius values greater than 0 will allow packets from more remote
>>       nodes to be accepted.
>> 
>>     Don't know if I'm simply rephrasing what you actually meant. In any case,
>>     we should fix the wording.
>> 
>>  2. If ACL update is done as described, it will deny packets that belong to other
>>     sessions of the same protocol between the same peers. If the intent was to
>>     use GTSM strictly on a per-protocol-session basis, then we need take
>>     protocol ports into consideration. If we don't, then we are really using it
>>     on a per protocol/ipaddress basis.
>> 
>>  3. For directly connected peers, do we also want to restrict the receive
>>     interface?
>> 
>> >                  It is assumed that a receive path ACL is an ACL
>> >                  that is designed to control which packets are
>> >                  allowed to go to the RP.  This procedure will only
>> >                  allow protocol packets from adjacent router to pass
>> >                  onto the RP.
>> > 
>> >           (b)  If the inbound TTL is less than 255 for a directly
>> >                connected peer, or less than
>> >                255-(configured-range-of-acceptable-hops) for a
>> >                multi-hop peer, the packet is NOT processed. Rather,
>> >                the packet is placed into a low priority queue, and
>> >                subsequently logged and/or silently discarded.  In
>> >                this case, an ICMP message MUST NOT be generated.
>> > 
>> >     (ii)  If GTSM is not enabled, normal protocol behavior is followed.
>> > 
>> > 
>> > 
>> > 3.1.  Multi-hop Scenarios
>> > 
>> > 
>> >    When a multi-hop protocol session is required, we set the expected
>> >    TTL value to be 255-(configured-range-of-acceptable-hops).  This
>>                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> Same confusion re the range vs value.
>>                      
>> >    approach provides a qualitatively lower degree of security for the
>> >    protocol implementing GTSM (i.e., a DoS attack could theoretically be
>> >    launched by compromising some box in the path).  However, GTSM will
>> >    still catch the vast majority of observed DDoS attacks against a
>>                                               ^
>>                                            "outsider"
>> 
>> >    given protocol. Note that since the number of hops can change rapidly
>> >    in real network situations, it is considered that GTSM may not be
>> >    able to handle this scenario adequately and an implementation MAY
>> >    provide OPTIONAL support.
>> > 
>> > 
>> > 
>> > 3.1.1.  Intra-domain Protocol Handling
>> > 
>> > 
>> >    In general, GTSM is not used for intra-domain protocol peers or
>> >    adjacencies.
>> 
>> Do you mean IGPs here? If so, is this an observation or a recommendation?
>> 
>> > The special case of iBGP peers can be protected by
>> >    filtering at the network edge for any packet that has a source
>> >    address of one of the loopback addresses used for the intra-domain
>> >    peering. In addition, the current best practice is to further protect
>> >    such peers or adjacencies with an MD5 signature [RFC2385].
>> ...
>> 
>> > 5.  Security Considerations
>> 
>> In addition to what's already there, this section should talk about on-the-wire
>> attacks, how typical they are in different deployment scenarios (e.g., routing
>> protocols in a SP network vs router-to-host protocols) and the need for real
>> security mechanisms.
>> 
>> 
>> We also need a section for the applicability statement. As I mentioned before,
>> it would need to make it very clear that this is a scheme that's only applicable
>> to environments with inherently limited topologies, to make sure people don't
>> try to apply it everywhere.
>> 
>> --
>> 
>> 
>> 
>> _______________________________________________
>> Rtgwg mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
Rtgwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rtgwg