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

From: Alex Zinin <[email-masked]>
Date: Fri, 8 Jul 2005 14:48:17 -0700

Returning to this old thread:

Based on the feedback we got on the list and I got privately, it appears I
went somewhat too far into details that will vary based on the
implementation, specifically the filtering engine. The burden is now on me
to revise my comments and distill them to what's essential for proper
behavior. I will review the discussion and do so soon to allow Dave to
submit the revision in time.

-- 
Alex
http://www.psg.com/~zinin

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

---

From: Alex Zinin <[email-masked]>
Date: Tue, 12 Jul 2005 16:12:49 -0700

Folks-

 On this issue (see quotes below), how about we say in the doc:

  Implementations MUST support the single-hop (TrustRadius = 0) mode, and
  MAY support the multi-hop (TrustRadius > 0) one.

--
Alex

>> >>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.

> 	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.  

>> >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.

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

---

From: Alex Zinin <[email-masked]>
Date: Tue, 12 Jul 2005 16:29:40 -0700

>> >>>  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.
>> >>
>> >>Could this issue be handled by requiring DF be set?  And the MTU used by
>> >>a protocol configured?

I'm not sure about this. IP fragments carrying a large OSPF packet are seen
in practice more than one would expect and DF'ing them would break OSPF's
legitimate operation.

This means the condition (TTL==255) && (!fragment) isn't a clear cut
anymore and you have to look further again.

>> >>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.

The approach I took in my comments on this doc was to leave the exact
details of how resources are separated for different classes to the
implementor and admin, and only specify what needs to be specified--the
defaults and only to make sure enabling GTSM doesn't bring the network
down.

So, what you say is correct. I'm just not sure we can or should capture
every valid choice here. I.e., one may want the GTSM defaults wrt Unknown
and Trusted separation is concerned to be exactly what they are without
GTMS--i.e. the same queue. That would be a valid design choice.

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

Not for all, but for all Unknown, and yes, my original comments did say
that for Unknown too.

>> >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.

Right. It's straight-forward with single-hop. With multi-hop, we should be
able to tell Unknowns from Dangerous.

--
Alex

---

From: Alia Atlas <[email-masked]>
Date: Wed, 13 Jul 2005 00:57:09 -0700

> Not for all, but for all Unknown, and yes, my original comments did say

Given that implementing GTSM for a particular protocol is to try and
protect it against such DOS attacks, letting the fragments have to
compete for resources with Unknown seems to make this much less useful
- as far as the multi-hop case goes.

> >> >there should not be fragments to receive...

Are there protocols where it is the case that both fragments are
commonly seen and the multi-hop case is necessary?

> able to tell Unknowns from Dangerous.

Since it is straight-forward with single-hop, why don't we call this
out in the draft as a special case where fragments with TTL=255 are
trusted?  At least that makes the single-hop case more useful.
 
Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 13 Jul 2005 01:00:11 -0700

Sounds good.  The only point with the MAY for the multi-hop is to
require that the packets are sent with the TTL=255 even if the
recipient is multiple hops away and the receiver doesn't support the
multi-hop.

Alia

---

From: Alex Zinin <[email-masked]>
Date: Wed, 13 Jul 2005 12:49:57 -0700

Alia,

> - as far as the multi-hop case goes.

What's the alternative?

> commonly seen and the multi-hop case is necessary?

OSPF VLs. On the other hand, they are not very widely deployed.
I don't recall anything else that doesn't run over TCP.

> trusted?  At least that makes the single-hop case more useful.

Seems a good idea to me. I would probably still check the IP addresses
though to make sure we don't mix frags from trusted neighbors with those
from untrusted.

Alex

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Jul 2005 09:12:59 +0300 (EEST)

> recipient is multiple hops away and the receiver doesn't support the

As I said in the past, I believe all this stuff about TrustRadius 
should go in an appendix, so that the main spec could be much simpler 
(e.g., related to fragments and text).

Then we could describe "a generalized GTSM" in the appendix.  The 
section would describe the differences to:
  - applicability
  - the GTSM rules themselves (instead of checking for "255" ...)
  - security considerations
  - (possibly) fragment processing
  - something else?

What I see now is that we're complicating the main spec with a 
generalization that I'm not sure people have implemented or are all 
that interested about.  The main spec is IMHO standards track maturity 
but the generalization still seems experimental to me.

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