IETF Logo Mail Archive

Re: [secdir] secdir review of draft-ietf-spring-segment-routing-13

David Mandelberg <david+work@mandelberg.org> Fri, 23 March 2018 22:17 UTC

Return-Path: <david+work@mandelberg.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4F612DDD0 for <secdir@ietfa.amsl.com>; Fri, 23 Mar 2018 15:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 wn0lLQEQRjnV for <secdir@ietfa.amsl.com>; Fri, 23 Mar 2018 15:17:23 -0700 (PDT)
Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2529712DDD2 for <secdir@ietf.org>; Fri, 23 Mar 2018 15:17:22 -0700 (PDT)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=Le5+0XXi c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=v2DPQv5-lfwA:10 a=bmmO2AaSJ7QA:10 a=48vgC7mUAAAA:8 a=BTUBnpS-AAAA:8 a=t_vtnJgi4ZqP-9O_qOAA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=pblkFgjdBCuYZ9-HdJ6i:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=david+work@mandelberg.org; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=david+work@mandelberg.org; spf=neutral; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN)
Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 209.6.43.168 is neither permitted nor denied by domain of mandelberg.org)
Received: from [209.6.43.168] ([209.6.43.168:42622] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from <david+work@mandelberg.org>) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 1D/69-58381-CEC75BA5; Fri, 23 Mar 2018 18:17:16 -0400
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id DC2871C609C; Fri, 23 Mar 2018 18:17:15 -0400 (EDT)
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-spring-segment-routing.all@ietf.org" <draft-ietf-spring-segment-routing.all@ietf.org>
References: <3b7c6cdc-0e9e-0a57-e030-ae3a715c6a03@mandelberg.org> <e32e5f9bc00043e3a8b86205d434c35d@XCH-ALN-001.cisco.com>
From: David Mandelberg <david+work@mandelberg.org>
Organization: David Mandelberg, LLC
Message-ID: <56ce2942-388f-d03b-721a-3b06af5559bc@mandelberg.org>
Date: Fri, 23 Mar 2018 18:17:14 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <e32e5f9bc00043e3a8b86205d434c35d@XCH-ALN-001.cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/X2vvj8aruHoBf87Hzh_ktMYunCk>
Subject: Re: [secdir] secdir review of draft-ietf-spring-segment-routing-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Mar 2018 22:17:24 -0000

Hi,

How will the indication of persistence be used? I scanned the changes 
from -13 to -15, but I didn't notice any other text about the new flag.

On 03/23/2018 06:34 AM, Les Ginsberg (ginsberg) wrote:
> David -
> 
> Apologies. It appears that I neglected to respond to this old review 
> comment.
> 
> This was not intentional. Authors actively discussed your comment 
> promptly and we did add text in V14 of the draft to address this point:
> 
> Please see: 
> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.4
> 
> /o  Indication whether the Adj-SID is persistent across control plane/
> 
> /      restarts.  Persistence is a key attribute in ensuring that an SR/
> 
> /      Policy does not temporarily result in misforwarding due to/
> 
> /      reassignment of an Adj-SID./
> 
> //
> 
> Please let us know if this adequately addresses your comment.
> 
> Again, apologies for the long delay.
> 
>     Les
> 
>  > -----Original Message-----
> 
>  > From: David Mandelberg <david@mandelberg.org>
> 
>  > Sent: Thursday, November 02, 2017 10:53 AM
> 
>  > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-spring-segment-
> 
>  > routing.all@ietf.org
> 
>  > Subject: secdir review of draft-ietf-spring-segment-routing-13
> 
>  >
> 
>  > I have reviewed this document as part of the security directorate's 
> ongoing
> 
>  > effort to review all IETF documents being processed by the IESG.  These
> 
>  > comments were written primarily for the benefit of the security area 
> directors.
> 
>  > Document editors and WG chairs should treat these comments just like any
> 
>  > other last call comments.
> 
>  >
> 
>  > The summary of the review is Ready with nits.
> 
>  >
> 
>  > This document affects routing within a trusted domain, and the security
> 
>  > considerations section adequately talks about filtering at the border 
> of a trusted
> 
>  > domain.
> 
>  >
> 
>  > I do have one question about something I didn't see in the document, what
> 
>  > happens when SIDs change while packets are in transit? Here's a 
> hypothetical
> 
>  > situation that could be bad for security, but I'm not sure whether or 
> not it could
> 
>  > happen: 1. An internal node calculates an SR Policy and sends out a 
> packet that
> 
>  > will eventually egress towards a BGP peer. 2. Multiple links on the 
> BGP router go
> 
>  > down and then back up, but are allocated different PeerAdj SIDs than 
> they had
> 
>  > before. 3. The packet reaches the BGP router, but egresses to the 
> wrong BGP
> 
>  > peer because the original PeerAdj SID is now mapped to a different 
> PeerAdj
> 
>  > segment.
> 
>  >
> 
>  > --
> 
>  > Freelance cyber security consultant, software developer, and more
> 
>  > https://david.mandelberg.org/
> 


-- 
Freelance cyber security consultant, software developer, and more
https://david.mandelberg.org/

v2.23.0 | Report a Bug | By Email