Re: [Isis-wg] Stephen Farrell's No Objection on draft-ietf-isis-extended-sequence-no-tlv-05: (with COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 21 April 2015 17:07 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F352B1A1A52; Tue, 21 Apr 2015 10:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 M93gnWiZI1AD; Tue, 21 Apr 2015 10:07:41 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72691A005A; Tue, 21 Apr 2015 10:07:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8C653BECA; Tue, 21 Apr 2015 18:07:38 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9jP76RERH74; Tue, 21 Apr 2015 18:07:37 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D12B0BEC9; Tue, 21 Apr 2015 18:07:36 +0100 (IST)
Message-ID: <553683D8.6090308@cs.tcd.ie>
Date: Tue, 21 Apr 2015 18:07:36 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Uma Chunduri <uma.chunduri@ericsson.com>, The IESG <iesg@ietf.org>
References: <20150421161402.15950.38407.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A60469152008633F651863@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F651863@eusaamb105.ericsson.se>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/7PV8LJGjDbmpA8Wd_L0fWf2p19w>
Cc: "draft-ietf-isis-extended-sequence-no-tlv.shepherd@ietf.org" <draft-ietf-isis-extended-sequence-no-tlv.shepherd@ietf.org>, "isis-chairs@ietf.org" <isis-chairs@ietf.org>, "chopps@chopps.org" <chopps@chopps.org>, "draft-ietf-isis-extended-sequence-no-tlv.ad@ietf.org" <draft-ietf-isis-extended-sequence-no-tlv.ad@ietf.org>, "draft-ietf-isis-extended-sequence-no-tlv@ietf.org" <draft-ietf-isis-extended-sequence-no-tlv@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] Stephen Farrell's No Objection on draft-ietf-isis-extended-sequence-no-tlv-05: (with COMMENT)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2015 17:07:43 -0000

Hiya,

Thanks, that all sounds fine. No need to check back with me
specifically unless you feel it's useful.

Cheers,
S.

On 21/04/15 17:59, Uma Chunduri wrote:
> Hi Stephen,
> 
> Thanks for your comments. In-line [Uma]:
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
> Sent: Tuesday, April 21, 2015 9:14 AM
> To: The IESG
> Cc: draft-ietf-isis-extended-sequence-no-tlv.shepherd@ietf.org; isis-chairs@ietf.org; chopps@chopps.org; draft-ietf-isis-extended-sequence-no-tlv.ad@ietf.org; draft-ietf-isis-extended-sequence-no-tlv@ietf.org; isis-wg@ietf.org
> Subject: Stephen Farrell's No Objection on draft-ietf-isis-extended-sequence-no-tlv-05: (with COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-isis-extended-sequence-no-tlv-05: No Objection
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-isis-extended-sequence-no-tlv/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - last para of section 5 (before 5.1) could do with a bit of a re-write, it's not very clear.
> [Uma]: Still working with Ben on this to address  his comment and shall confirm with you too after the change to see if it is any better.
> 
> - section 7: When this mechanism is used, can an attacker who can delete or re-order packets (which is v. similar to one who can replay
> packets) cause any new bad outcomes due to the verification of the out-of-order arrival? (Sorry, I don't know IS-IS enough to know the answer there, it's probably obvious.) If so, then maybe that argues that one ought note that this doesn't address such threats (but that this is still I guess worthwhile).
> 
> [Uma]: Out of ordered packets with lower sequence numbers would naturally be discarded by the receiving node. In that sense this feature actually helps for some 
>                 IS-IS PDUs where there is no  mechanism in place before this doc. But if the packets are deleted/not-forwarded then this mechanism can't mitigate  the situation. 
>                 This is kind of documented in https://tools.ietf.org/html/rfc6862#section-3.3 , I can state this particular aspect and refer the same in Section 7. 
>                Does this address your concern? Thx!
> 
>