GMPLS Segment Recovery
draft-ietf-ccamp-gmpls-segment-recovery-03

[Ballot comment]
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.

IANA Last Call Comments:

As noted in the Last Call announcement some of the registrations
required by this Internet Draft depend on previous approval of
another document. That document is draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04.txt.

Upon approval of this document and the document upon which it
depends ,
the IANA will make the following registrations.

In the "Association Types" Registry created by
located
in the "ASSOCIATION (object)" section of the "RSVP PARAMETERS"

registry located at
http://www.iana.org/assignments/rsvp-parameters the following assignment will be added:

Value Type
----- ----
2 Resource Sharing (R)

In the "Class Names, Class Numbers, and Class Types" section of
the "RSVP PARAMETERS" registry located athttp://www.iana.org/assignments/rsvp-parameters
two new classes will be added:

Class
Number Class Name Reference
------ ----------------------- ---------
tbd SECONDARY_EXPLICIT_ROUTE [RFC-ccamp-gmpls-segment-recovery]

Class Types or C-Types:

1 Type 1 Explicit Route [RFC3209]

Sub-object type
1 IPv4 prefix [RFC3209]
2 IPv6 prefix [RFC3209]
3 Label [RFC3473]
4 Unnumbered Interface ID [RFC3477]
32 Autonomous system number [RFC3209]
37 Protection [RFC-ccamp-gmpls-segment-recovery]

tbd SECONDARY_ROUTE_RECORD [RFC-ccamp-gmpls-segment-recovery]

Class Types or C-Types:

1 Type 1 Route Record [RFC3209]

Sub-object type
1 IPv4 address [RFC3209]
2 IPv6 address [RFC3209]
3 Label [RFC3473]
4 Unnumbered Interface ID [RFC3477]
5 RRO Attributes [RFC4420]
37 Protection [RFC-ccamp-gmpls-segment-recovery]

In the "Routing Problem" subsection of "Error Codes and Values"
section of the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters the following
subcode will be added

Error Code Meaning
24 Routing Problem [RFC3209]

tbd = LSP Segment Protection Failed [RFC-ccamp-gmpls-segment-recovery]

IANA understands that these are the only actions to be taken
upon approval of this document.

[Ballot comment]
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?