[email protected]
[Top] [All Lists]

Re: Comments on draft-ietf-rtgwg-rfc3682bis-05.txt

Subject: Re: Comments on draft-ietf-rtgwg-rfc3682bis-05.txt
From: Pekka Savola
Date: Fri, 27 May 2005 22:23:59 +0300 EEST
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.
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)..
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
If it would be feasible, I'd move single-hop GTSM to standards track
while keeping multihop at experimental.
  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...

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
Rtgw[email protected]

<Prev in Thread] Current Thread [Next in Thread>