Re: [karp] Supporting Authentication Trailer for OSPFv3

Uma Chunduri <uma.chunduri@ericsson.com> Mon, 18 October 2010 18:04 UTC

Return-Path: <uma.chunduri@ericsson.com>
X-Original-To: karp@core3.amsl.com
Delivered-To: karp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432F13A6B97; Mon, 18 Oct 2010 11:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level:
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNtmnsdsPe8q; Mon, 18 Oct 2010 11:04:27 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id BAD553A6DDE; Mon, 18 Oct 2010 11:04:26 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o9II5rOG016445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Oct 2010 13:05:54 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.27]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 18 Oct 2010 14:05:52 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>, "ospf@ietf.org" <ospf@ietf.org>, "karp@ietf.org" <karp@ietf.org>
Date: Mon, 18 Oct 2010 14:05:50 -0400
Thread-Topic: Supporting Authentication Trailer for OSPFv3
Thread-Index: ActfY5sckmQl7a6EQfCfdawAHpKrwgMk6FCwALtrHmA=
Message-ID: <D1D8138DDF34B34B8BC68A11262D10790AD751FFFB@EUSAACMS0701.eamcs.ericsson.se>
References: <7C362EEF9C7896468B36C9B79200D8350CF3CBA6B4@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350CF3F39B29@INBANSXCHMBSA1.in.alcatel-lucent.com>
In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3F39B29@INBANSXCHMBSA1.in.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [karp] Supporting Authentication Trailer for OSPFv3
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Oct 2010 18:04:29 -0000

Hi,

Though the spirit of the draft is good, I have few comments on draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt. 

1. Page 3 - Sec 1 - I saw couple of places referencing [RFC4522], LDAP?? 

2. Sec 2.2 
   I didn't understand on what exactly is the requirement that this has to be similar to OSPFv2?

3. Sec 3:
   - Mentions Key-ID is 32 bit?? But from Figure-3 it's 8 bit?
   - Do you need to consider any thing in draft-housley-saag-crypto-key-table-04.txt? It suggests 16 Bit Key-IDs
     (this could be important as in future it should be tied to AKMs for RPs?)
   - Probably, it's better to be more than  8 bit to facilitate association lkup from the DB.

4. Sec 4.1

   - Figure-3 (Reserved , instead of 0?)
   - Key-ID length inconsistency
 
5. Sec 4.2
    
   - I understand the proposal made is similar to OSPFv2 - but as this as any way new for OSPF3 does it have to be limited to HMAC-xxx?
     Can AES-XCBC-xx  be considered (to give more choice and for differentiation) 
        - not questioning HMAC-SHA-256, HMAC-SHA-384 etc..
        - as said to facilitate more options (in-built crypto accelerators)

6. Sec 4.3

   - It would be better if this sections show what is input/output to the crypto and what is authenticated through 1-2 figures?
   - Probably HMAC/crypto aspect can be as part of Appendix (..you can keep the APAD aspect here)

7. Would it be better to include IPv6 header too as part of OSPF3 packet (..not only as current available AH option  gives this protection)
   
Thanks,
Uma

-----Original Message-----
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, October 14, 2010 4:36 PM
To: ospf@ietf.org; karp@ietf.org
Subject: [OSPF] Supporting Authentication Trailer for OSPFv3

Hi,

We have posted the new version of this draft for the WG to review.

Changes from -00:

o Uses a new option bit (AT) present in the Hellos and DDs to indicate that the router will use an Authentication trailer in all OSPFv3 packets on that link. This will obviously be negotiated and the routers will only do this if both the routers turn on the AT bit.

o Describes where the new authentication trailer is placed wrt link local signaling (LLS) block defined in RFC5613.

o Some editorial changes.

Acee, Vishwas and Manav

> -----Original Message-----
> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf 
> Of Bhatia, Manav (Manav)
> Sent: Wednesday, September 29, 2010 4.50 AM
> To: ospf@ietf.org
> Subject: [OSPF] draft-bhatia-manral-auth-trailer-ospfv3-00.txt
> 
> 
> Hi,
> 
> Proposing another mechanism for doing non Ipsec authentication for 
> OSPFv3. In this proposal the OSPFv3 authentication information is 
> appended to the OSPFv3 packet and is not considered a part of the 
> protocol payload; it is instead included in the IPv6 packet's payload 
> length.
> 
> The mechanism described is very similar to how it is done for
> OSPFv2 and implementations can reuse most of the existing code for 
> authenticating OSPFv2.
> 
> So whats the difference between this and the 
> draft-bhatia-karp-non-ipsec-ospfv3-auth-01.txt?
> 
> The main difference is that the latter introduces a new IPv6 extension 
> header that can be used by all protocols that want to use non IPSec 
> security. The main issue that I see is that while it is generic I 
> don't see too many applications that might want to use this. The 
> advantage of the new mechanism is that its restricted to OSPFv3 and is 
> also backward compatible. Implementations that don't support this 
> extension can continue to ignore this trailer attached to the OSPFv3 
> payload.
> 
> The other difference is regarding the code reusability. In the new 
> mechanism (Authentication Trailer) very little new code needs to be 
> added, while the earlier (Generic Authentication Header) mechanism 
> would require new source code to be added.
> 
> Would be great if the WG can review this document!
> 
> Cheers, Manav
> 
> ----- Forwarded Message ----
> From: "Internet-Drafts@ietf.org" <Internet-Drafts@ietf.org>
> To: i-d-announce@ietf.org
> Sent: Tue, September 28, 2010 11:15:01 PM
> Subject: I-D ACTION:draft-bhatia-manral-auth-trailer-ospfv3-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
>     Title        : Supporting Authentication Trailer for OSPFv3 
>     Author(s)    : M. Bhatia, V. Manral
>     Filename    : draft-bhatia-manral-auth-trailer-ospfv3-00.txt
>     Pages        : 12
>     Date        : 2010-9-28
>     
> Currently OSPFv3 uses IPsec for authenticating the protocol 
>       packets. There however are some environments (mobile ad-hoc), 
>       where IPsec is difficult to configure and maintain, and this 
>       mechanism cannot be used. This draft proposes an alternative 
>       mechanism that can be used so that OSPFv3 does not depend upon 
>       IPsec for security.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bhatia-manral-auth-t
> railer-ospfv3-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> --
> Manav Bhatia,
> IP Division, Alcatel-Lucent,
> Bangalore - India
> 
>  
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> 
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf