Subject: GTSM to STD track?

From: Alex Zinin <[email-masked]>
Date: Thu, 20 May 2004 14:31:30 -0700

Folks-

 Dave and I talked about putting a revision of GTSH on STD tracks as a
 DoS-prevention mechanism. I'd like to know what folks in the WG think about
 this idea. Yes/No/"what's STD tracks"?

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

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 May 2004 07:19:29 +0300 (EEST)

>  this idea. Yes/No/"what's STD tracks"?

Definitely for STDs track, especially as it has to be revised in any 
case ASAP!

-- 
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: "Joel M. Halpern" <[email-masked]>
Date: Fri, 21 May 2004 12:50:24 -0400

Assuming that the operational folks agree that this is as good an idea as 
it appears (which is rather supported by the operational background of the 
authors), I would support some form of standardization for GTSM.
Looking at the draft, it looks to me like a better candidate for BCP than 
for Proposed Standard.  Given that the on-the-wire behavior of the 
protocols is not changed (one of the positive features of this approach) it 
would be awkward to describe it as a proposed standard protocol.

Yours,
Joel M. Halpern

At 02:31 PM 5/20/2004 -0700, Alex Zinin wrote:
>Folks-
>
>  Dave and I talked about putting a revision of GTSM on STD tracks as a

---

From: Tony Tauber <[email-masked]>
Date: Fri, 21 May 2004 10:50:01 -0700 (PDT)

On Fri, 21 May 2004, Joel M. Halpern wrote:
> >  Dave and I talked about putting a revision of GTSM on STD tracks
> >  as a DoS-prevention mechanism. I'd like to know what folks in the
> >  WG think about this idea. Yes/No/"what's STD tracks"?
>
> Assuming that the operational folks agree that this is as good an
> idea as it appears (which is rather supported by the operational
> background of the authors), I would support some form of
> standardization for GTSM.  Looking at the draft, it looks to me like
> a better candidate for BCP than for Proposed Standard.  Given that
> the on-the-wire behavior of the protocols is not changed (one of the
> positive features of this approach) it would be awkward to describe
> it as a proposed standard protocol.
>
> Yours,
> Joel M. Halpern

Yes, I'm also not sure what kind of Standard it would be.
It's not a protocol and I'm not sure there are interoperability
ramifications or not (would depend on the specifics, I guess.)

Pehaps a BCP to operators and implementors and guidance to designers
of future protocols?

Tony

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 May 2004 14:16:46 -0400

> ramifications or not (would depend on the specifics, I guess.)

In a sense it is a protocol extension to IPv4/v6.  It might even
be worth having those groups review this.

The main interoperability issue is that if you configure this on
a host to communicate with another host that doesn't support the feature
you may send the packets *much* farther than you otherwise might, especially
when communicating with non directly connected hosts.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Fri, 21 May 2004 23:10:31 -0700

To add to Jeff's points:

We do change bits on the wire (TTL setting) and the input packet processing
rules (packet discrimination, ICMP generation.)

As an interop-related ramification, following or not following the spec will
also affect:

 a) whether the receiving side (using GTSM) accepts your packets with TTL < 255,
    or (in the extreme case) drops them on the floor, AND:

 b) whether the GSTM-enabled side can expect the other side to cooperate and
    hence whether a certain level of DoS protection can be assumed.

Joel, Tony, does this make sense?
    
At the end of the day, the question is: "Is GTSM an important enough DoS
prevention mechanism for the IETF to have Standard on it?"

That said, if we decide to put it on the STD track, we will certainly need to
review the document with the STD glasses on and see what changes would be
needed.

-- 
Alex

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 22 May 2004 02:27:04 -0400

I will admit that we are regularly fuzzy about what constitutes suitability 
for PS vs BCP.

I do not think we should use "important enough" as a measure for whether it 
is PS.  Some very important pieces have ended up BCP.

I have trouble seeing the setting of an existing field to an existing valid 
value as a protocol change.  This is advice on configuration.  Particularly 
since the way it is used depends upon the particularly topological 
placement of the communicating peers.

It sure seems to be good advice.  And if you really feel strongly that it 
is important to make it PS, I won't scream during last call.  I just think 
it is better suited to BCP.

Yours,
Joel M. Halpern

---

From: Tony Tauber <[email-masked]>
Date: Mon, 24 May 2004 06:15:27 -0700 (PDT)

On Fri, 21 May 2004, Alex Zinin wrote:

> To add to Jeff's points:
>
> We do change bits on the wire (TTL setting) and the input packet
> processing rules (packet discrimination, ICMP generation.)
>
> As an interop-related ramification, following or not following the
> spec will also affect:
>
>  a) whether the receiving side (using GTSM) accepts your packets
>  with TTL < 255, or (in the extreme case) drops them on the floor,
>  AND:
>
>  b) whether the GSTM-enabled side can expect the other side to
>  cooperate and hence whether a certain level of DoS protection can
>  be assumed.

Would something change based on that assumption?  I hadn't thought of
it, but might the router CPU stand down from a more defensive posture
as a result (eg. regarding treatment of input queues or the like?)
If some real decision is made based on this mechanism, one would need
some positive capability negotiation, etc.  Then concerns about
authenticating those messages pop up.  I'm inclined to suggest advice
against such a presumption unless the mechanism is built into the
protocol itself; eg. there are no other modes of operation.

> At the end of the day, the question is: "Is GTSM an important enough
> DoS prevention mechanism for the IETF to have Standard on it?"

Put that way, it begs the question, "a standard for what?"

Is it just for routing protocols or are there other subnet-local cases
which could benefit?  In terms that spoofing packets from off-net is
now considered an expected threat though it wasn't years ago, there's
value in "standard-izing".

I'm in favor but some thought and words should be put toward
applicability.

Tony

>
> That said, if we decide to put it on the STD track, we will
> certainly need to review the document with the STD glasses on and
> see what changes would be needed.
>
> --
> Alex