The Generalized TTL Security Mechanism (GTSM)
draft-ietf-rtgwg-rfc3682bis-10

Note: This ballot was opened for revision 09 and is now closed.

Jari Arkko Yes

Section 5.4 conclusions apply only if the GTSM processing
cannot associate initial and non-initial fragments to
each other. There does not seem to be any reason why
this could not be done; the GTSM processor is the receiver
of the packets and can look at the identifier field. If
the initial fragment belongs to a session, the non-initial
fragments have the same identifier, and all fragments satisfy
the TTL criteria, it would seem that we can make equally
strong conclusions about the packet as we can from a
non-fragmented packet.

Am I missing something?

Anyway, I fully support the recommendation to use path
MTU discovery and avoiding fragments. Please consider
the above question mostly from an acamedic interest
point of view.

(Ross Callon) Yes

(David Ward) Yes

(Ron Bonica) No Objection

Section 6: The applicability statement is pretty good about saying that the value of GTSM is inversely proportional to the hop-count between the neighboring peers. However, you might want to add a sentence that says that GTSM will not protect you against attackers who are as close to the protected station as its legitmate peer. For example, if the legitimate peer is one hop away, GTSM will not protect from attacks from directly connected devices.

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

Section 5.4., paragraph 3:
>    As such, it is highly recommended for GTSM-protected protocols to
>    avoid fragmentation and reassembly by manual MTU tuning, using
>    adaptive measures such as Path MTU Discovery (PMTUD), or any other
>    available method.

  Suggest to add a reference to RFC 4821 for PMTUD and make it the
  preferred alternative for avoiding fragmentation. (And shouldn't this
  be a capital RECOMMENDED?)

(Sam Hartman) (was Discuss) No Objection

I dislike it when documents speak of "trusted" packets, interfaces or
peers without a discussion of what they are trusted to do.  In this
instance, I think all devices on a trusted interface are trusted not
to originate packets with spoofed source address, hop limit or TTL.
Also, the physical hardware of trusted links is trusted not to have
unintended peers on the link.

It would be great if this were refined and included in the document.

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

There is no place in the document that mentions that this standards track RFC would obsolete an Experimental RFC. I believe that the Abstract and the Appendix B 'Changes Since RFC3682' should mention that 3682 was Experimental.

(Mark Townsley) No Objection

(Magnus Westerlund) No Objection