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

From: Alex Zinin <[email-masked]>
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-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 May 2005 09:15:29 +0300 (EEST)

> there are any objections on what the document say MUST, SHOULD, or MAY

I don't have objections to the proposed text (and I do think it makes 
sense to push GTSM on standards track soon because the spec clarifies 
a number of things and is very useful), but I have a couple of 
observations:

  1) in 3.3, I don't think you can say "[the less specific entries] are 
replaced with a more speficic entry".  I think you mean in 2.3 that 
when a session is torn down, the more specific entry needs to be 
replaced again with less specific entries. I mean, how do you deal 
with a spurious TCP session reset?  These GTSM filtering engine has to 
be robust enough to allow establishing a new session after the BGP 
session is torn down and is being brought up again, using different 
ports.

IMHO, creating the more specific entries is against the spirit of 
original GTSM -- the whole point was that if you're directly 
connected, you're "semi-trusted".  I as an operator don't care all 
that much about the port sweep threat in that case.  I'd suggest 
moving the "more specific filter installation" case over to an 
appendix with a couple of health warnings.

At the very least, if there is consensus to keep it as is, there 
should be equal amount of specification what needs to be done when 
sessions fail than as when sessions are created.  Further, there are 
cases where one end of the session thinks the session is down, and the 
other thinks it's still up -- these rules make failover more difficult 
in this case.

  2) it strikes me when you describe the filtering rules that equal 
kind of filtering (just without the TTL) is applicable for the 
non-GTSM sessions as well, to counter the threat of an attack using 
Unknown state.  But I'm not sure if this spec is the right place to 
stay that, maybe in an appendix..

  3) In section 3, you talk about ECMP etc. -- to me that's a pretty 
non-interesting part.  do people really want to run GTSM between 
sessions which aren't directly connected?  It doesn't seem like an 
appropriate mechanism for there.  The security ADs are likely going to 
want to see a clearer applicability statement here. I wouldn't be sad 
to see the whole TrustRadius thing eliminated or moved to appendix. 
But I assume this is a moot argument.

  ...

A couple of nits:
  - Security people may flinch at the use of "Trusted" classification. 
If another suitable name could be used, great.  If not, we'll see 
later if this is a problem.
  - Instead of addresses in 10/8, please use 192.0.2.0/24.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alia Atlas <[email-masked]>
Date: Wed, 25 May 2005 18:38:12 -0400

Dave, Alex, et al,

Just a few comments on reviewing this.

In the Intro, it restricts this technique to TCP/IP.  Is there a reason 
that this wouldn't work for plain IP as well?   I see that Alex in talking 
about IP fragments is discussing this applying to OSPF packets.

In 3.1.1, it says that GTSM SHOULD NOT be used for intra-domain protocol 
peers.  Why not?  This seems to be a useful mechanism for, say, LDP for 
those adjacencies that are non-targeted.  What is the rationale here?
I gather that the technique was first thought of in regards to BGP - but 
there are references to LDP as well and it could be useful for that.

>     associated with GTSM-enabled protocol sessions MUST be set to 255.

This is a potentially new forwarding plane requirement.  For all other 
traffic, it is acceptable to decrement the TTL of packets egressing the 
router.

If the multi-hop GTSM were being used - why is it necessary to transmit 
with a TTL=255?

>     cryptographic authentication.

I wouldn't say that the GTSM packet identification MUST be applied before 
general IP processing.  For instance, the verification of an IPv4 header 
checksum might be in hardware before the ACLs are applied.  I think what 
you mean is that the GTSM packet identification step MUST be applied before 
any non-line-rate processing is applied.  Of course, this assumes that the 
hardware is line-rate :-)  so I'm sure a better phrasing is needed.

>              #  Identification params                 TTL range

This makes the forwarding plane require more than just an existing ACL 
lookup.  Now, the look-up must contain not merely permit/deny, but 
potentially a range of TTL values & the ability to check them.  That can be 
rather expensive.

If the additional processing required for those particular packets subject 
to the GTSM process were to cause the forwarding plane to be unable to due 
the GTSM process at line-rate, then there's no benefit, I think.

I think it may be useful to describe that it is possible to support only 
the single-hop GTSM - which gives the most security benefit, anyway.  That 
seems to me to be much simpler to implement with the currently existing ACLs.

Also, I think one could put the TTL check into the ACL, if it is for an 
exact value.  One would put the specific rule with TTL=255 & a 
less-specific rule with TTL=*.  That would catch the conforming & 
non-conforming separately.

>   o MAY drop packets classified as Dangerous.

Is there any requirement on the resource-sharing behavior between Unknown 
and Trusted?  Is it desirable for there to be?

>   o Such unidentified fragments SHOULD NOT be dropped (as part of GTSM

Could this issue be handled by requiring DF be set?  And the MTU used by a 
protocol configured?

If unidentified fragments are classified as Unknown and Unknown packets can 
share resources with Trusted, then there doesn't seem to be much additional 
security from the mechanism.  The attacker can just send fragments instead.

This policy suggested for fragments seems to be merely the same policy that 
could be applied to all packets, whether fragments or not.

Could you explain/clarify a bit more?

Thanks,
Alia

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 May 2005 22:23:59 +0300 (EEST)

> traffic, it is acceptable to decrement the TTL of packets egressing the 

I don't understand what you're saying.  This isn't a forwarding plane 
requirement.  It just says that the certain packets originated by the 
router must have TTL set to specific value.

> If the multi-hop GTSM were being used - why is it necessary to transmit with 
> a TTL=255?

Uhh, unless you send with TTL=255, the receiver can't verify what the 
sender's TTL was (and the number of hops that were traversed)..

[...]
> If the additional processing required for those particular packets subject to 
> the GTSM process were to cause the forwarding plane to be unable to due the 
> GTSM process at line-rate, then there's no benefit, I think.
>
> I think it may be useful to describe that it is possible to support only the 
> single-hop GTSM - which gives the most security benefit, anyway.  That seems 
> to me to be much simpler to implement with the currently existing ACLs.

Personally, I don't care for non-single-hop GTSM at all (and I think 
it would probably be dangerous and requires an applicability 
statement.

If it would be feasible, I'd move single-hop GTSM to standards track 
while keeping multihop at experimental.

> could be applied to all packets, whether fragments or not.

Good idea; if the application protocol were to always set the DF bit, 
then there should not be fragments to receive...

---

From: Alia Atlas <[email-masked]>
Date: Fri, 27 May 2005 23:04:19 -0400

At 03:23 PM 5/27/2005, Pekka Savola wrote:
>>traffic, it is acceptable to decrement the TTL of packets egressing the router.
>

Packets originated by the control plane need to go through the forwarding 
plane to exit the correct interface.  That hardware may or may not 
decrement the TTL, depending on architecture, config, etc.

I'm not saying that it is a large problem - but it could be pulled out a 
bit more explicitly.

>sender's TTL was (and the number of hops that were traversed)..

Yes, but if one were using multi-hop, one could configure the accepted 
values to be 1 more than otherwise necessary, for instance.

>>potentially a range of TTL values & the ability to check them.  That can 
>>be rather expensive.
>>
>>If the additional processing required for those particular packets 
>>subject to the GTSM process were to cause the forwarding plane to be 
>>unable to due the GTSM process at line-rate, then there's no benefit, I think.
>>
>>the single-hop GTSM - which gives the most security benefit, 
>>anyway.  That seems to me to be much simpler to implement with the 
>>currently existing ACLs.
>
>Personally, I don't care for non-single-hop GTSM at all (and I think it 
>would probably be dangerous and requires an applicability statement.
>
>If it would be feasible, I'd move single-hop GTSM to standards track while 
>keeping multihop at experimental.

I agree.  I believe the multi-hop has a less clear benefit & more holes.
At the least, it would be good to more clearly describe the added 
complexity and risks (or lesser benefit) for the multi-hop and possibly 
make those MAY instead of SHOULD.

>>Could this issue be handled by requiring DF be set?  And the MTU used by 
>>a protocol configured?
>>
>>If unidentified fragments are classified as Unknown and Unknown packets 
>>can share resources with Trusted, then there doesn't seem to be much 
>>additional security from the mechanism.  The attacker can just send 
>>fragments instead.
>>
>>This policy suggested for fragments seems to be merely the same policy 
>>that could be applied to all packets, whether fragments or not.
>
>Good idea; if the application protocol were to always set the DF bit, then 
>there should not be fragments to receive...

Alternately, if one were only doing single-hop GTSM, then trusting 
fragments with a TTL of 255 wouldn't be a concern.

Alia

---

From: Pekka Savola <[email-masked]>
Date: Sat, 28 May 2005 09:33:09 +0300 (EEST)

On Fri, 27 May 2005, Alia Atlas wrote:
> plane to exit the correct interface.  That hardware may or may not decrement 
> the TTL, depending on architecture, config, etc.
>
> I'm not saying that it is a large problem - but it could be pulled out a bit 
> more explicitly.

I'm not sure if "forwarding" is the exactly right word here, but there 
is indeed a problem if the packets originated by the control plane 
need to be "forwarded" by the router.

I'd prefer to just say that the TTL must not be decremented, and it's 
the implementer's design choice how to deal with GTSM in a system 
architecture that does that, but if these implementations are too 
common, it might not be sufficient.

---

From: David Meyer <[email-masked]>
Date: Tue, 31 May 2005 13:23:20 -0700

> I'm not saying that it is a large problem - but it could be pulled out a 

	We did have some language in the original document that
	discussed this point, and the differences between
	vendors; however it seems we removed that at some
	point. I'll resurrect that...

> values to be 1 more than otherwise necessary, for instance.

	This possibility was also considered in
	draft-ietf-rtgwg-rfc3682bis-05.txt, along with its
	interactions with various tunneling scenarios.

> >would probably be dangerous and requires an applicability statement.

	Its there already:

	  When a multi-hop protocol session is required, we set
	  the expected TTL value to be 255 - TrustRadius. This
	  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
	  (launched from outside the network) against a 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.  

> make those MAY instead of SHOULD.

	I have no problem with this. Multi-hop GTSM has (clearly)
	"less well defined" behavior and security properites.

> fragments with a TTL of 255 wouldn't be a concern.

	Yep, agree.

	Dave