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

[Sean Turner <[e-mail]>]

Mahesh,

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
  security:

  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
   supported.

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

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:

OLD:

  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.

NEW:

  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.

spt


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:
>> http://www.ietf.org/internet-drafts/draft-mahesh-karp-rsvp-te-analysis-00.txt
>> Status: http://datatracker.ietf.org/doc/draft-mahesh-karp-rsvp-te-analysis
>> Htmlized: http://tools.ietf.org/html/draft-mahesh-karp-rsvp-te-analysis-00
>>
>>
>> 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
> [e-mail] <mailto:[e-mail]>
>
>
>
>
>
> _______________________________________________
> karp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/karp
>