[email protected]
[Top] [All Lists]

Re: Comments on draft-ietf-rtgwg-rfc3682bis-05.txt: single-hop/multi-hop

Subject: Re: Comments on draft-ietf-rtgwg-rfc3682bis-05.txt: single-hop/multi-hop
From: Pekka Savola
Date: Thu, 14 Jul 2005 09:12:59 +0300 EEST
On Wed, 13 Jul 2005, Alia Atlas wrote:
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.
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.
On 7/12/05, Alex Zinin <[email protected]> wrote:
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.


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

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

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

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

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