Re: [karp] New Version Notification for draft-mahesh-karp-rsvp-te-analysis-00.txt

Sean Turner <> Thu, 28 February 2013 14:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA9F321F85AF for <>; Thu, 28 Feb 2013 06:30:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.238
X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dHLIP-qDj6Uv for <>; Thu, 28 Feb 2013 06:30:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1B65B21F84B8 for <>; Thu, 28 Feb 2013 06:30:53 -0800 (PST)
Received: by (Postfix, from userid 5007) id AB9AEA4AD5EB8; Thu, 28 Feb 2013 08:30:52 -0600 (CST)
Received: from ( []) by (Postfix) with ESMTP id 9646EA4AD5E4D for <>; Thu, 28 Feb 2013 08:30:52 -0600 (CST)
Received: from [] (port=49733 helo=thunderfish.local) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1UB4VY-0004rU-10; Thu, 28 Feb 2013 08:30:52 -0600
Message-ID: <>
Date: Thu, 28 Feb 2013 09:30:50 -0500
From: Sean Turner <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Mahesh Jethanandani <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-Sender: (thunderfish.local) []:49733
X-Email-Count: 4
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: Re: [karp] New Version Notification for draft-mahesh-karp-rsvp-te-analysis-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Feb 2013 14:30:54 -0000


Thanks to you and your co-authors for beating me to this.  Stephen 
Farrell and I actually met with Lou Berger at IETF 85 to lament how RSVP 
is always the last one pick.  We figured if anybody was going to do this 
analysis it's be one of us - very glad we were wrong.

Couple questions (Q#) and some nits (N#):

Q1: I think s2 basically says that RSVP-TE uses RSVP so the rest of the 
draft is just going to talk about RSVP.  If that's the case why not move 
the idea of the 2nd paragraph of s2 to the 2nd to paragraph last in the 
intro. Maybe something like:

   Resource Reservation Protocol (RSVP) is a resource
   reservation setup  protocol designed for an integrated
   services [RFC2205].  RSVP Cryptographic Authentication
   [RFC2747] describes the format and use of RSVP's
   INTEGRITY objects to provide hop-by-hop integrity and
   authentication of RSVP messages.  RSVP-TE [RFC3209]
   is an extension of the RSVP protocol to establish
   Multi-Protocol Label Switching (MPLS) Label Switch
   Paths (LSPs).  RSVP-TE signaling is used to establish
   both intra- and inter-domain TE LSPs.

   NOTE: RSVP is not discussed in this document because
   it is not in scope for the KARP WG.

N1: abstract/intro: expand RSVP and RSVP-TE

N2: abstract: r/[RFC6518]/RFC 6518 (no reference in abstract)

N3: s1: r/suggests/suggested (matches with described)

N4: s1: Maybe instead of "The OPSEC working group ...

  This document builds on several previous analysis efforts into routing

  o [RFC6039] describes issues with existing cryptographic
     protection methods for routing protocols
  o [draft-ietf-karp-ospf-analysis-03] analyzes OSPF security
    according to KARP Design Guide
  o [draft-ietf-karp-routing-tcp-analysis] analyzes TCP based
    protocols including BGP, LDP, PCEP, and MSDP

Q2: s2: Don't we need a section on underlying transport where we can use 
the text from RFC 2205 tell everybody that it runs directly over IP:

  2.1.  Transport Layer

  RSVP operates on top of IPv4 or IPv6, occupying the place of a
  transport protocol in the protocol stack.  However, RSVP does not
  transport application data but is rather an Internet control
  protocol, like ICMP, IGMP, or routing protocols.


Q3: Do we need to discuss UDP encapsulation?

Q4: s2: How about a new subsection (kind of matches the tcp analysis draft):

  2.2.  Keying mechanisms

   There is no automated key management (AKM) mechanism for RSVP.  If
   implemented manual key management is used.

  and grab the 2nd to last paragraph and stick it in this section.

Q5: s2: Is there a current requirement (that came before the IAB 
workshop) on authenticating RSVP headers and payloads?  In this section 
maybe we just say:

  2.3.  Message Integrity and Node Authentication

   RSVP-TE makes use of the RSVP Cryptographic Authentication
   [RFC2747].  Note that there is currently no RSVP-TE
   specific security mechanism.

   RSVP Cryptographic Authentication defines the use of HMAC-MD5
   for both message integrity and node authentication.  The length
   of the keyed digests is 128 bits and the RSVP checksum can be
   disabled in lieu of message digest.  No algorithm agility is

   There is no requirement that the RSVP-TE headers and payload be

Q6: RSVP discusses user authentication for policy control and secure 
data streams.  Is the policy control stuff used?

N5: I'd also probably just have subsections for:

  2.*  Replay Protection
  2.*  Out-of-Order Protection
  2.*  Denial Of Service Protection

Where the appropriate text from the existing section gets copied.

N6: s3 2nd para: I think the point is that the current mechanism doesn't 
support cryptographic agility:


  In RSVP Cryptographic Authentication [RFC2747], only the usage of MD5
  to generate digests for RSVP-TE messages is mentioned.  In order to
  fulfill the requirement of supporting strong algorithms, at least the
  support of SHA-2 needs to be provided.


  In RSVP Cryptographic Authentication [RFC2747], only the usage of MD5
  to generate digests for RSVP-TE messages is defined.  In order to
  fulfill the requirement of supporting strong algorithms and
  cryptographic algorithm agility, at least the
  support of SHA-2 and the ability to indicate additional algorithms
  needs to be provided.


On 12/19/12 11:52 PM, Mahesh Jethanandani wrote:
>> A new version of I-D, draft-mahesh-karp-rsvp-te-analysis-00.txt
>> has been successfully submitted by Mahesh Jethanandani and posted to the
>> IETF repository.
>> Filename:     draft-mahesh-karp-rsvp-te-analysis
>> Revision:     00
>> Title:         Analysis of RSVP-TE Security According to KARP Design Guide
>> Creation date:     2012-12-16
>> WG ID:         Individual Submission
>> Number of pages: 12
>> URL:
>> Status:
>> Htmlized:
>> Abstract:
>> This document analyzes RSVP-TE according to guidelines set forth in
>> section 4.2 of KARP Design Guidelines [RFC6518].
>> The IETF Secretariat
> Mahesh Jethanandani
> <>
> _______________________________________________
> karp mailing list