Re: [OSPF] AD review of draft-ietf-ospf-security-extension-manual-keying-08

Alia Atlas <akatlas@gmail.com> Fri, 03 October 2014 21:11 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6D11A7029 for <ospf@ietfa.amsl.com>; Fri, 3 Oct 2014 14:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1exn0CNBbtwu for <ospf@ietfa.amsl.com>; Fri, 3 Oct 2014 14:11:51 -0700 (PDT)
Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B641A854B for <ospf@ietf.org>; Fri, 3 Oct 2014 14:11:09 -0700 (PDT)
Received: by mail-yk0-f175.google.com with SMTP id 19so637427ykq.34 for <ospf@ietf.org>; Fri, 03 Oct 2014 14:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AniyrevgqSfjQD2/ezS6HnfCssiNrJ511NcJHx6VzA4=; b=nBZjvHeD/40fZ7S/e4UA9mKbslqA/mEmQsJFSePaVQ9c4kdowwSPpPWjvcfA3X4OAo 8Px7JouR2AGbUi0GzFkOOb8V/cSLhBUStkpiNrBWiznBLhO6lqeXlK+EKsPHdR+qfuJp QDjaXnZC1AiHOsL4nBMsDRt/0omU5TMFaKkj67Z9H1sbUTyDSGNLskqVureGAQFdU/2u yWWN6N+ogDssDc3vb+VTYgimtvaQ1/6oKI720uqr9jH8UB1JPbpIk6R2iLxqZMulZ0vo UlisDbXFIg2Z/OsNxK50Dmxq+CJtzjyPkf4hpmWt35t80l3dg+uW16rHZBlZthzHByU8 nYSA==
MIME-Version: 1.0
X-Received: by 10.236.131.134 with SMTP id m6mr11358801yhi.3.1412370668444; Fri, 03 Oct 2014 14:11:08 -0700 (PDT)
Received: by 10.170.113.134 with HTTP; Fri, 3 Oct 2014 14:11:08 -0700 (PDT)
In-Reply-To: <D0547BDF.4208%acee@cisco.com>
References: <CAG4d1re30HP7ZneZh6Nt=tnU3im2oXBVj-zTxRTfsnota4VTtw@mail.gmail.com> <D0547BDF.4208%acee@cisco.com>
Date: Fri, 03 Oct 2014 17:11:08 -0400
Message-ID: <CAG4d1rcsxgQNQPO60-mULP4jCi=tfA9h+bSNDmEsteDs=0VPSA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Content-Type: multipart/alternative; boundary="20cf300e5071fbe0bb05048b2b61"
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/MpN1XeCkcef4upfQuAvqSqFBQ78
Cc: OSPF List <ospf@ietf.org>, Ospf Chairs <ospf-chairs@tools.ietf.org>, "draft-ietf-ospf-security-extension-manual-keying@tools.ietf.org" <draft-ietf-ospf-security-extension-manual-keying@tools.ietf.org>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-security-extension-manual-keying-08
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 03 Oct 2014 21:11:54 -0000

Hi Acee,

On Fri, Oct 3, 2014 at 4:34 PM, Acee Lindem (acee) <acee@cisco.com> wrote:

>  Hi Alia,
> Thanks for the review. See inline.
>
>   From: Alia Atlas <akatlas@gmail.com>
> Date: Friday, October 3, 2014 at 3:52 PM
> To: Ospf Chairs <ospf-chairs@tools.ietf.org>, "
> draft-ietf-ospf-security-extension-manual-keying@tools.ietf.org" <
> draft-ietf-ospf-security-extension-manual-keying@tools.ietf.org>, Vishwas
> Manral <vishwas.ietf@gmail.com>, OSPF WG List <ospf@ietf.org>
> Subject: [OSPF] AD review of
> draft-ietf-ospf-security-extension-manual-keying-08
>
>   As I do with all drafts that are ready to progress, I have done my AD
> review of this
> draft-ietf-ospf-security-extension-manual-keying-08.  In this case, I
> apologize for it taking so long.
>
>  The draft is very clear and well-written.  I do have a few comments, but
> I have sent it to IETF Last Call for review while we discuss.  Assuming
> that goes smoothly and comments (including mine below) are taken into
> account, I expect the draft to go to IESG telechat for Oct 30.
>
>  Major Comment:
>
>  My one concern is that in Section 3, it says:
>
>  "Additionally, the 64-bit sequence number is moved to the first 64-bits
> following the OSPFv2 packet and is protected by the authentication
> digest."
>
>  but I do not see any other place where RFC 5709 is updated to include
> that sequence number.  In Sec 3.3, RFC 5709 says:
>
>     First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet))
>
>
> and I think it would be most excellent for this draft to clearly
>
> update that to be (OSPFv2 Packet + Sequence Number).
>
>
>  With this draft, we attempted to avoid Stephen Farrell’s ire by not
> repeating the authentication algorithm as we have done when apply SHAx-HMAC
> authentication to each routing protocol. Note that RFC 5709 includes the
> statement:
>
>    Implementation Notes:
>
>           Note that the First-Hash above includes the Authentication
>           Trailer containing the Apad value, as well as the OSPF packet,
>           as per RFC 2328, Section D.4.3.
>
> In section 5, we wukk add:
>
>                            The 64-bit sequence number will be included in
> the First-Hash along with the Authentication
>                            Trailer and OSPF packet (Refer to Section 3.3
> in RFC 5709).
>

That sounds good to add to clarify the point.


>  Minor Comments:
>
>
> Should the meta-data and header indicate that this updated RFC 5709?  It certainly looks like it.
>
>
>  I don’t feel strongly on this. However, this is a new type of OSPFv2
> cryptographic authentication and RFC 5709 authentication will continue to
> be supported by implementations that support it. So, one could argue that
> it updates RFC 2328 rather than RFC 5709. The whole issue of when to use
> the “Updates” would be a good topic for WG chair discussion.
>

I believe (and Adrian may have additional perspective) that Updates is
appropriate when a new implementation should use the updated RFC.  Of
course there will be implementations that stay RFC 5709 compliant.  Looking
more closely, I would agree that this draft should update both RFC 2328
(due to the packet format) and RFC 5709 (due to the algorithm changes).
Using Updates provides nice pointers to both RFCs.

I'd recommend bringing up the question of when the use "Updates" in the
next chairs' chat.  I'll
add it to my list of potential topics.

Thanks,
Alia

 Thanks,
> Acee
>
>
>
>
> Thanks for the hard work on a good draft to make routing more secure!
>
>
> Alia
>
>
>