Skip to main content

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

Yes

(David Ward)
(Ross Callon)

No Objection

(Chris Newman)
(Cullen Jennings)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Russ Housley)
(Tim Polk)

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

David Ward Former IESG member
Yes
Yes () Unknown

                            
Jari Arkko Former IESG member
Yes
Yes (2007-06-21) Unknown
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 Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection (2007-06-18) Unknown
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.
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection (2007-06-20) Unknown
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?)
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (2007-06-18) Unknown
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.
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
(was Discuss) No Objection
No Objection (2007-06-17) Unknown
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.
Tim Polk Former IESG member
No Objection
No Objection () Unknown