Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-auth-trailer-ospfv3-05.txt> (Supporting Authentication Trailer for OSPFv3) to Proposed Standard

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 24 August 2011 14:50 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296D221F8BAB; Wed, 24 Aug 2011 07:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.266
X-Spam-Level:
X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M52X7HeBlzNF; Wed, 24 Aug 2011 07:50:06 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEA821F8B8A; Wed, 24 Aug 2011 07:50:06 -0700 (PDT)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p7OEpAri021455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Aug 2011 09:51:13 -0500 (CDT)
Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7OEp9dF030370 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 24 Aug 2011 20:21:09 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 24 Aug 2011 20:21:09 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Acee Lindem <acee.lindem@ericsson.com>
Date: Wed, 24 Aug 2011 20:21:08 +0530
Thread-Topic: [OSPF] [karp] Last Call: <draft-ietf-ospf-auth-trailer-ospfv3-05.txt> (Supporting Authentication Trailer for OSPFv3) to Proposed Standard
Thread-Index: AcxibJ0W8exhPoa4TDCkVUgqhZqnuAAAC72A
Message-ID: <7C362EEF9C7896468B36C9B79200D8350CFF9A5F06@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <20110719145739.5942.53564.idtracker@ietfa.amsl.com> <tsl7h6ed1sp.fsf@mit.edu> <7C362EEF9C7896468B36C9B79200D8350CFF9A5F02@INBANSXCHMBSA1.in.alcatel-lucent.com> <8D54DD3C-45C6-4C34-9CD3-DF6B6C758B4E@ericsson.com> <1D4A7913-4FE3-4B9F-9D0D-9FBC5E12F56E@ericsson.com>
In-Reply-To: <1D4A7913-4FE3-4B9F-9D0D-9FBC5E12F56E@ericsson.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
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: "ospf@ietf.org" <ospf@ietf.org>, Sam Hartman <hartmans-ietf@mit.edu>, "ietf@ietf.org" <ietf@ietf.org>, "karp@ietf.org" <karp@ietf.org>
Subject: Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-auth-trailer-ospfv3-05.txt> (Supporting Authentication Trailer for OSPFv3) to Proposed Standard
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2011 14:50:07 -0000

Hi Acee,

> >> 
> >> We change the hex that's repeated in the Apad from 
> 0x878FE1F3 to 0x878FE1F4. This value will be unique for 
> OSPFv3. Other protocols that use this mechanism must use a 
> different value of Apad - you could think of this as 
> "salting" the Apad.
> > 
> > Could we simply use the OSPFv3 protocol number, 89, in the 
> Apad, e.g., 0x898FE1F4,  (or at least the first instance of 
> Apad). Otherwise, we probably need a registry for IANA Apads. 
> 
> I meant 0x898FE1F3 as to not change the last 3 octets of the 
> existing HMAC-SHAx Apad. 

We would still need an IANA registry of Apads unless youre thinking of using the IP protocol type as the first octet of the Apad. If it's the latter, then OSPFv3 and OSPFv2 would share the same Apad, which would defeat the purpose of the whole exercise.

This would also not work for multiple protocols that ride over UDP and TCP. BFD and RIP would end up using the same Apad as their IP protocol is the same. 

We thus need a unique Apad that each standard can define if we want to protect ourselves from the attack that Sam describes.

Cheers, Manav