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 router.
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.
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 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 think.
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.
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.
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
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