RE: Request for WG adoption of

Santosh P K <santoshpk@juniper.net> Wed, 25 November 2015 17:42 UTC

Return-Path: <santoshpk@juniper.net>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7893A1A7014; Wed, 25 Nov 2015 09:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 PF7pKTlfqFVH; Wed, 25 Nov 2015 09:42:43 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171D81A7013; Wed, 25 Nov 2015 09:42:42 -0800 (PST)
Received: from SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) by SN1PR0501MB2142.namprd05.prod.outlook.com (10.163.228.157) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 17:42:21 +0000
Received: from SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) by SN1PR0501MB2142.namprd05.prod.outlook.com ([10.163.228.157]) with mapi id 15.01.0331.019; Wed, 25 Nov 2015 17:42:21 +0000
From: Santosh P K <santoshpk@juniper.net>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Subject: RE: Request for WG adoption of
Thread-Topic: Request for WG adoption of
Thread-Index: AdEnqJ1JY1P3qht/QZqVnplssSGb8w==
Date: Wed, 25 Nov 2015 17:42:21 +0000
Message-ID: <SN1PR0501MB2142E7903231D58F569890DBB3050@SN1PR0501MB2142.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net;
x-originating-ip: [116.197.184.14]
x-microsoft-exchange-diagnostics: 1; SN1PR0501MB2142; 5:43shno23OXI0Q20NrCVFr0jm5SWgHhlFadsJN1aT5CbCcV5syxD8sxgNVFE1jxRIl17LbuT3sWqxbhYfIQwFXQT+fY5mLBpFdZszEzeDx8h6F686MtpqHNZQEk8b137sbqzbdlPjV1Ji5uGs1B/BSg==; 24:5RQTvSrz04hukTDCWjLAUeSWhvQdl3+lz/PXv1vA79SA3ifgKCMz4FG3xyfQw+SMxCWvBcYYO/JFGUCqxpCmRgBEJvSaVHDZPBTgIHzZPXY=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB2142;
x-microsoft-antispam-prvs: <SN1PR0501MB2142A8668E94B7C793FC0A53B3050@SN1PR0501MB2142.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0501MB2142; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB2142;
x-forefront-prvs: 0771670921
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(24454002)(199003)(189998001)(19580395003)(19625215002)(790700001)(3846002)(33656002)(87936001)(86362001)(15975445007)(5003600100002)(6116002)(5002640100001)(5001960100002)(101416001)(19300405004)(102836003)(586003)(97736004)(5004730100002)(11100500001)(74316001)(2900100001)(5008740100001)(40100003)(50986999)(19609705001)(54356999)(1411001)(5007970100001)(76576001)(19580405001)(16236675004)(110136002)(105586002)(66066001)(81156007)(122556002)(77096005)(92566002)(99286002)(106356001)(10400500002)(1220700001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB2142; H:SN1PR0501MB2142.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB2142E7903231D58F569890DBB3050SN1PR0501MB2142_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 17:42:21.0162 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB2142
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-bfd/ys51PyBN-Us5dE4NbHssN0RJTFg>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "draft-mahesh-bfd-authentication@ietf.org" <draft-mahesh-bfd-authentication@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2015 17:42:48 -0000

Mahesh,
  Thanks for quick reply. Please see some points from old mail. I think we need to make document more clear bout some ambiguity with authentication enabled.

<snip>

I think we need to do this randomly for few times to get rid of any attack when BFD session is UP. Consider a case where BFD can run at interval of  3.3 ms only if  no authentication is enabled.  So with initial slow packets (>1 sec when not UP) I will be authenticating the packets and when session goes to UP state with aggressive interval BFD will go without AUTH. If I want to send BFD packet with AUTH then I might need to change the interval first?



Secondly I think we will terminate Auth once the BFD session goes to UP state locally and I assume some configuration will decide how randomly to send BFD UP packets with AUTH set. Now assume that BFD on one end is stuck in INIT state due to packet loss (2 packet loss if multiple is 3), so for 2 seconds one side which has already reach UP state might have terminated AUTH and other side in INIT might have not. This could lead to time mismatch on when to randomly send UP packets with Auth set. I think we need to have proper guidelines on when to terminate the AUTH and when to start again may be with P/F negotiation?
<snip>

Thanks
Santosh P K

From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
Sent: Wednesday, November 25, 2015 11:06 PM
To: Santosh P K <santoshpk@juniper.net>
Cc: Reshad Rahman (rrahman) <rrahman@cisco.com>; rtg-bfd@ietf.org; draft-mahesh-bfd-authentication@ietf.org
Subject: Re: Request for WG adoption of


On Nov 25, 2015, at 3:48 AM, Santosh P K <santoshpk@juniper.net<mailto:santoshpk@juniper.net>> wrote:

But I think there are few things to consider in this document. It needs to clearly highlight how to handle interval change from non-aggressive interval to aggressive interval.

A interval change requires a P/F sequence, which are authenticated packets.

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>