Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt

"Acee Lindem (acee)" <acee@cisco.com> Thu, 31 July 2014 13:47 UTC

Return-Path: <acee@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC881B280F for <rtg-dir@ietfa.amsl.com>; Thu, 31 Jul 2014 06:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 59r5VvOmEocl for <rtg-dir@ietfa.amsl.com>; Thu, 31 Jul 2014 06:47:38 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35811B2804 for <rtg-dir@ietf.org>; Thu, 31 Jul 2014 06:47:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11249; q=dns/txt; s=iport; t=1406814458; x=1408024058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Dpa/OzJdtCChJlGAeCT0+gtI6Pd/23fh+AefwBRtzT4=; b=HYc8hzTXU8aTGE5Pu2Sg6vZTXEcXFLiX4NrktrlCwWFA6YYr/4UG+5Bk fUixUdfyxukFCWNjcGWWvya+vR4NgvPnz9n2V+bLpkioMIBwl2HTAFOex MaTR2cobEareiGPI4uOMe29vGLqk/M9/9tOvtGONeYA+ETxz3le8UXQCl E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0FAGxI2lOtJV2Z/2dsb2JhbABZgkdHUlcEyyyHSwGBBhZ3hAMBAQEBA3kQAgEIEQMBAigHIREUCQgBAQQBDQUJEogTAxENtR4Nhw4XjR+CHBEHhEoFjmWIWYIhggWOLoYlg0lsAYEEJBw
X-IronPort-AV: E=Sophos;i="5.01,772,1400025600"; d="scan'208,217";a="344112939"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 31 Jul 2014 13:47:21 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6VDlLt7028695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 13:47:21 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 31 Jul 2014 08:47:21 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: manav bhatia <manav@ionosnetworks.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Thread-Topic: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt
Thread-Index: Ac+shGzPWBGyWOV8RaCVb10qJlxIvwAX4yoA///UtYA=
Date: Thu, 31 Jul 2014 13:47:20 +0000
Message-ID: <CFFFBE99.15F1%acee@cisco.com>
References: <F3ADE4747C9E124B89F0ED2180CC814F23E88A19@xmb-aln-x02.cisco.com> <CAGS6MpBU=3+JwsNCFK=-3JYSknKSHhktpqUhtGrgpuQoQHRP8Q@mail.gmail.com>
In-Reply-To: <CAGS6MpBU=3+JwsNCFK=-3JYSknKSHhktpqUhtGrgpuQoQHRP8Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.152.195]
Content-Type: multipart/alternative; boundary="_000_CFFFBE9915F1aceeciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/hwdzzQBNA34fafPLy3996_QF28Q
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-karp-bfd-analysis@tools.ietf.org" <draft-ietf-karp-bfd-analysis@tools.ietf.org>, "zhangdacheng@huawei.com" <zhangdacheng@huawei.com>, "all@tools.ietf.org" <all@tools.ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, "mjethanandani@gmail.com" <mjethanandani@gmail.com>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Jul 2014 13:47:40 -0000

Hi Manav,
I agree with Les though I may have logged this as a major issue. What if the next-hop used to reach your NTP server is validated using authenticated multi-hop BFD?  Also, It is seems a bit superficial to recommend usage of UTC for the high order 32 bits of the sequence number without dealing without mentioning the 2038 wrap for the UNIX time.
Thanks,
Acee

From: Manav Bhatia <manav@ionosnetworks.com<mailto:manav@ionosnetworks.com>>
Date: Thursday, July 31, 2014 at 8:22 AM
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Cc: "rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>" <rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>>, "draft-ietf-karp-bfd-analysis@tools.ietf.org<mailto:draft-ietf-karp-bfd-analysis@tools.ietf.org>" <draft-ietf-karp-bfd-analysis@tools.ietf.org<mailto:draft-ietf-karp-bfd-analysis@tools.ietf.org>>, "zhangdacheng@huawei.com<mailto:zhangdacheng@huawei.com>" <zhangdacheng@huawei.com<mailto:zhangdacheng@huawei.com>>, "all@tools.ietf.org<mailto:all@tools.ietf.org>" <all@tools.ietf.org<mailto:all@tools.ietf.org>>, "rtg-ads@tools.ietf.org<mailto:rtg-ads@tools.ietf.org>" <rtg-ads@tools.ietf.org<mailto:rtg-ads@tools.ietf.org>>, "mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>" <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-karp-bfd-analysis-04.txt

Hi Les,

Thanks for the comments.



Minor Issues: I am a little surprised that the use of UTC is emphasized as a means of preventing replay attacks. While this is certainly a viable solution what has been more commonly used by a number of other protocols is reserving a portion of the sequence number for a boot count. In fact this is the way that http://www.ietf.org/id/draft-ietf-bfd-generic-crypto-auth-06.txt  has chosen. Yet this document chooses to emphasize UTC encoding.



I am the author of the standards that started using the boot count initially as a way to preserve the crypto sequence count. I am not a big fan of UTC and this was suggested as a plausible mechanism that did not appear to be outright loony (especially when you have increased the seq space to 64 bits). Let me put it this way - I wouldnt be baying for blood if the directorate believes that this is a retrogressive step and we need to snip out that section.


Nits:



1)The affiliation for one of the authors (Manav) is inconsistent in the header vs the authors addresses section.

Will fix this. For the record, i now work for Ionos Networks.




2)In the Introduction the last sentence of the second paragraph reads:



"Moving the routing protocols to a stronger

   algorithm while using weaker algorithm for BFD would require the

   attacker to bring down BFD in order to bring down the routing

   protocol. "

I think what is meant is that if the BFD authentication algorithm is weaker than that used by the routing protocols it is more likely to be the target of an attack. The phrase "require the attacker..." seems inappropriate.

Gotcha. Will fix this.




3)Section 3 last sentence of the penultimate paragraph:



s/reply/replay

.. and this.




4)Section 6 Second paragraph second sentence



s/notion/the notion

.. and this as well.

Thanks,

Manav



Thanx.



   Les