Subject: [karp] [Karp] New Version Notification for draft-zheng-mpls-ldp-hello-crypto-auth-02.txt, please comment.

From: Vero Zheng <[email-masked]>
Date: Tue, 19 Jul 2011 11:28:36 +0800

A new version of I-D, draft-zheng-mpls-ldp-hello-crypto-auth-02.txt has been
successfully submitted by Lianshu Zheng and posted to the IETF repository.

Abstract:
   This document introduces a new optional Cryptographic Authentication
   TLV that LDP can use to secure its Hello messages.  It secures the
   Hello messages against spoofing attacks and some well known attacks
   against the IP header.  This document describes how the National
   Institute of Standards and Technology (NIST) Secure Hash Standard
   family of algorithms should be used to secure LDP Hello messages.

Hi all,

We have submitted the new version of the
draft-zheng-mpls-ldp-hello-crypto-auth-02, it could be found at the URL
http://tools.ietf.org/html/draft-zheng-mpls-ldp-hello-crypto-auth-02

Per WG discussion, we introduced a 64-bit strictly increasing sequence
number that is used to guard against replay attacks. The 64-bit sequence
number MUST be incremented for every LDP packet sent by the LDP router.
Upon reception, the sequence number MUST be greater than the sequence number
in the last LDP packet accepted from the sending LDP neighbor.  In case it
isnt, the LDP packet is considered a replayed packet and is dropped.

LDP routers implementing this specification SHOULD use available mechanisms
to preserve the sequence number's strictly increasing property for the
deployed life of the LDP router (including cold restarts).  Techniques such
as sequence number space partitioning and non-volatile storage preservation
can be used but are beyond the scope of this specification.

We have also fixed the hash computing mistake in this update.

Please review it and comment.

BR,
Mach, Manav and Vero

> -----Original Message-----
> From: Bhatia, Manav (Manav) [mailto:[email-masked]]
> Sent: Monday, April 04, 2011 5:35 AM
> To: Mach Chen; zhenglianshu 50128
> Cc: [email-masked]
> Subject: draft-zheng-mpls-ldp-hello-crypto-auth
> 
> Hi,
> 
> The current version of draft-zheng-mpls-ldp-hello-crypto-auth does not
contain
> any cryptographic sequence numbers and I spoke to Mach and Vero about this
> in Prague. It seems that they were told that replay attacks are not
considered
> a big deal for LDP. While I can concede that replay attacks are a trifle
more
> difficult for LDP deployments (mostly service providers environment) I am
not
> comfortable in developing a solution that precludes the possibility of us
ever
> supporting this.
> 
> Given this I would like to suggest the following change in the draft:
> 
> We either define a new 4 byte field for crypto-sequence numbers that the
> implementations MAY chose to ignore or define two Auth types where one
> contains this field and the other doesn't.
> 
> Also I just noticed that the TLV defines Auth Type which indicates the
kind of
> algo being used. I think this is redundant and I see no need for this
given that
> we are already carrying a Key ID.
> 
> Cheers, Manav
> 
> --
> Manav Bhatia,
> IP Division, Alcatel-Lucent,
> Bangalore - India
> 
>

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Wed, 20 Jul 2011 01:49:39 +0000

Hello, everybody:

Manav and I have proposed a draft of the gap analysis on BFD. 

Analysis of Bidirectional Forwarding Detection (BFD) Security According
                          to KARP Design Guide
                draft-bhatia-zhang-karp-bfd-analysis-01

Abstract

   This document analyzes the Bidirectional Forwarding Detection
   protocol (BFD) according to the guidelines set forth in section 4.2
   of draft-ietf-karp-design-guide.

We had the draft discussed in the BFD WG and updated it according to the collected comments. Could you please have a look ? Any comments will be appreciated. ^_^

All the best!

Dacheng