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

[Pekka Savola <[e-mail]>]

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 <[e-mail]> 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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/rtgwg
>>
>
> _______________________________________________
> Rtgwg mailing list
> [e-mail]
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/rtgwg