On Fri, May 27, 2005 at 11:04:19PM -0400, Alia Atlas wrote:
> At 03:23 PM 5/27/2005, Pekka Savola wrote:
> >On Wed, 25 May 2005, Alia Atlas wrote:
> >>> The TTL field in all IP packets used for transmission of messages
> >>> associated with GTSM-enabled protocol sessions MUST be set to 255.
> >>This is a potentially new forwarding plane requirement. For all other
> >>traffic, it is acceptable to decrement the TTL of packets egressing the
> >I don't understand what you're saying. This isn't a forwarding plane
> >requirement. It just says that the certain packets originated by the
> >router must have TTL set to specific value.
> Packets originated by the control plane need to go through the forwarding
> plane to exit the correct interface. That hardware may or may not
> decrement the TTL, depending on architecture, config, etc.
> I'm not saying that it is a large problem - but it could be pulled out a
> bit more explicitly.
We did have some language in the original document that
discussed this point, and the differences between
vendors; however it seems we removed that at some
point. I'll resurrect that...
> >>If the multi-hop GTSM were being used - why is it necessary to transmit
> >>with a TTL=255?
> >Uhh, unless you send with TTL=255, the receiver can't verify what the
> >sender's TTL was (and the number of hops that were traversed)..
> Yes, but if one were using multi-hop, one could configure the accepted
> values to be 1 more than otherwise necessary, for instance.
This possibility was also considered in
draft-ietf-rtgwg-rfc3682bis-05.txt, along with its
interactions with various tunneling scenarios.
> >>This makes the forwarding plane require more than just an existing ACL
> >>lookup. Now, the look-up must contain not merely permit/deny, but
> >>potentially a range of TTL values & the ability to check them. That can
> >>be rather expensive.
> >>If the additional processing required for those particular packets
> >>subject to the GTSM process were to cause the forwarding plane to be
> >>unable to due the GTSM process at line-rate, then there's no benefit, I
> >>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
> >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.
> >>> 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?
> >>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.
> >>This policy suggested for fragments seems to be merely the same policy
> >>that could be applied to all packets, whether fragments or not.
> >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.
Rtgwg mailing list