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
On 7/12/05, Alex Zinin <[email protected]> wrote:
> 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.
> >> >>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]
Rtgwg mailing list