IETF Logo Mail Archive

Re: [spring] Brian Haberman's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS and COMMENT)

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Wed, 24 February 2016 13:33 UTC

Return-Path: <sprevidi@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54A01B2B97; Wed, 24 Feb 2016 05:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level:
X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 qZp6RK7t-rCo; Wed, 24 Feb 2016 05:33:02 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6EA71B2B5F; Wed, 24 Feb 2016 05:33:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3750; q=dns/txt; s=iport; t=1456320781; x=1457530381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cWacRI7Ji01GHoegeTgXpX7rS9fSME1J3Y5X/qRE8F4=; b=avNBXJMnw+I9m/l2RXqBBQnw8fDUpglIh0qNBtMe0CiwJdk7/7ekOUTd /Z/5CnGC/Qe2VMicfsfqEC8l+Wh+c2/GZM1I96b+/2zoWiaBOXo9uGl+p gblyTw1B0YSxcnIyQi8SEgiT6YP5GqrkOoZ4XQZs9CbbtKQObV8CNGbff E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAgBhsM1W/5ldJa1egzpSbQa4U4ITAQ2BZiGFbAIcgSE4FAEBAQEBAQFkJ4RBAQEBAgEBIxE0EQULAgEIGAICJgICAjAVEAIEDgUJEgGHewgOrxiOaQEBAQEBAQEBAQEBAQEBAQEBAQEBARV7hReBbAiCRoQzgwIrgQ8Fh1aLHYQUAYhFhRmOdI5IAR4BAUKCMIE0agGGYn0BAQE
X-IronPort-AV: E=Sophos;i="5.22,493,1449532800"; d="scan'208";a="74260388"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2016 13:33:00 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1ODX0AA001977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 13:33:01 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 07:33:00 -0600
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 07:33:00 -0600
From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
To: Brian Haberman <brian@innovationslab.net>
Thread-Topic: Brian Haberman's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS and COMMENT)
Thread-Index: AQHRXo05HDFvnCJsDE6gn/H3wkxEjZ87tzmA
Date: Wed, 24 Feb 2016 13:33:00 +0000
Message-ID: <9605CC68-EAF3-4868-ABDC-87F51B837F89@cisco.com>
References: <20160203141439.18637.21969.idtracker@ietfa.amsl.com>
In-Reply-To: <20160203141439.18637.21969.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.228.219]
Content-Type: text/plain; charset="utf-8"
Content-ID: <64B0A072A368A34E80C3FB3D6038AF4B@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/spring/QcotZ3fBG7O-txUstTb5_9unddo>
Cc: "spring@ietf.org" <spring@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>, The IESG <iesg@ietf.org>, "Pierre Francois (pifranco)" <pifranco@cisco.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "<draft-ietf-spring-problem-statement@ietf.org>" <draft-ietf-spring-problem-statement@ietf.org>
Subject: Re: [spring] Brian Haberman's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS and COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2016 13:33:03 -0000

Hi,

See below some comments.

> On Feb 3, 2016, at 3:14 PM, Brian Haberman <brian@innovationslab.net> wrote:
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The following is a training review from the Suresh Krishnan (incoming INT
> AD)
> 
> * Section 3.4
> 
> If the intent is to create a new RH type how will the interoperability or
> backward compatibility be possible? Specifically because intermediate
> nodes (that are segment routing hops) that encounter unknown RH types are
> required to drop the packet and send an ICMPv6 Parameter Problem back.


in fact, RFC2460 states that if a node is the destination of a packet with a unknown routing header type, it must inspect “segments_left” field and if its 0, then the RH is ignored (and the packet regularly processed).

Therefore, as you pointed out, it is required and assumed that any intermediate segment supports the new RH type described in draft-ietf-6man-segment-routing-header.

Still segment routing allows interoperability with non-SR nodes since only segment nodes must be SR capable. 

Text will be added to draft-ietf-6man-segment-routing-header in order to clarify this point but I’m not sure if draft-ietf-spring-problem-statement should incorporate this level of details.


> * Security considerations
> 
> In general this document does not talk anything about the security issues
> with IPv6 routing headers and how they would be avoided. e.g. The
> following paper describes an attack.
> 
>   [CanSecWest07]  Biondi, P. and A. Ebalard, "IPv6 Routing Header
>                   Security", CanSecWest Security Conference 2007,
>                   April 2007.
>                   http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
> 
> I think the security considerations are very light and need to be greatly
> improved.


Security aspects of the IPv6 Segment Routing Header are described in section 5 of draft-ietf-6man-segment-routing-header. 


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> * Section 2
> 
> This section talks about the Routing header defined in RFC2460 but does
> not mention that the RH0 has been deprecated by RFC5095. Potentially
> worth mentioning draft-ietf-6man-segment-routing-header-00.


SR for IPv6 is implemented through a new type. 

As the problem-statement draft is not supposed to contain any solution description, all the aspects of the new routing header type are described in draft-ietf-6man-segment-routing-header.

s.

v2.23.0 | Report a Bug | By Email