GMPLS Segment Recovery
draft-ietf-ccamp-gmpls-segment-recovery-03
Yes
(Ross Callon)
No Objection
(Brian Carpenter)
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lars Eggert)
(Magnus Westerlund)
(Mark Townsley)
(Sam Hartman)
(Ted Hardie)
Note: This ballot was opened for revision 03 and is now closed.
Ross Callon Former IESG member
Yes
Yes
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
(2006-10-25)
Unknown
Reference to draft-lang-ccamp-gmpls-recovery-e2e-signaling should probably be updated to draft-ietf-ccamp-gmpls-recovery-e2e-signaling via RFC Editor note so it doesn't hang waiting for a document that will never come.
Brian Carpenter 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
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert 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
Russ Housley Former IESG member
No Objection
No Objection
(2006-10-24)
Unknown
From SecDir Review by Ran Canetti: There is the need to authenticate RSVP communication that is not hop-by-hop (hbh). (Note: This authentication is not for the purpose of end-to-end contents integrity, but rather to protect the RSVP protocol from spoofing and resource grabbing by outsiders.) RFC 3437, which uses non-hbh RSVP communication, contains an off-hand suggestion to use generic IPsec for this communication (since RFC 2747 doesn't apply). But the suggestion is not nearly detailed enough to be of real standards value. What about compromised RSVP routers? This concern is not mentioned in any RSVP-related RFC that I saw. What is the damage that can be done by a compromised router? How can this damage be limited/contained? What is the extent to which a compromised RSVP router can damage non-RSVP traffic? Also, what about false advertisements by RSVP routers? Can clients verify that they get the bandwidth allocation they paid for?
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown