Re: Feedback on the use of Hop-by-Hop options extension header (draft-francois-dots-ipv6-signal-option-01)

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Sun, 12 February 2017 21:32 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182C712944F for <ipv6@ietfa.amsl.com>; Sun, 12 Feb 2017 13:32:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 llsD7w5upVvv for <ipv6@ietfa.amsl.com>; Sun, 12 Feb 2017 13:32:13 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43504129439 for <ipv6@ietf.org>; Sun, 12 Feb 2017 13:32:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2538; q=dns/txt; s=iport; t=1486935133; x=1488144733; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NQam+ify6Mdc3yHUSnig5gvZR/bPUptoGO5M4zO10eY=; b=KUjQgo3DB2eI+T8x113v1YQ90aVOTFyWRdZflx8p02VXL/GQV+lxjBZ9 2KmeW6HQYVMT7lt13ZSaL+uG5NmfVoNYkIa06eq/tjtndhheCEAEh+o9I 0WZbNcaBZSqMcn4j4hteZeF+Aoqlh30KY5+U/FyKPz7SFH2KrGYzBicrM E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASBAAr06BY/40NJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1JhgQkHgwxGigiRa5VVggwfC4RogRACGoJhPxgBAgEBAQEBAQF?= =?us-ascii?q?iKIRqAgQBAQoXETobAgEGAhoCHwcCAgIlCxUQAgQBEolqDpEVnU6CJYtAAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBC4VBggUIgmKEMCQXgm8ugjEFiQQIh32KaQG?= =?us-ascii?q?GboslkQWTFAEfOIEAURU9EQGEaYFIdYgDgTCBDAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.35,154,1484006400"; d="scan'208";a="384613230"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2017 21:32:12 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1CLWB0e007613 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 12 Feb 2017 21:32:11 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 12 Feb 2017 15:32:10 -0600
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Sun, 12 Feb 2017 15:32:10 -0600
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: =?utf-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= <jerome.francois@inria.fr>, IPv6 List <ipv6@ietf.org>
Subject: Re: Feedback on the use of Hop-by-Hop options extension header (draft-francois-dots-ipv6-signal-option-01)
Thread-Topic: Feedback on the use of Hop-by-Hop options extension header (draft-francois-dots-ipv6-signal-option-01)
Thread-Index: AQHSgexA+tIhASIbY0OUHbTwbIvHzqFmYFGA
Date: Sun, 12 Feb 2017 21:32:10 +0000
Message-ID: <2229AA3E-5686-4FA0-9A4F-669CE7937FCA@cisco.com>
References: <589AE235.6080808@inria.fr>
In-Reply-To: <589AE235.6080808@inria.fr>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.215.210]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4BF448BFBA535A4B93964040FABA8F82@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vwl1BW5XglLj7PviCLrxYB6xi9M>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Feb 2017 21:32:15 -0000

Jérôme,

I am sure that you know about draft-brockners-inband-oam-transport-02.

The common sense dictates that a node should not act on a HbH extension header which cannot be trusted (obvious DoS) but I see no problem when a node SELECTIVELY and on purpose (as opposed to 'by default') acts on HbH extension headers. (I fully agree with Fred's expired draft-ietf-6man-hbh-header-handling-03)

Hope this helps

Bien à toi,

-éric


On 08/02/17 10:17, "ipv6 on behalf of Jérôme François" <ipv6-bounces@ietf.org on behalf of jerome.francois@inria.fr> wrote:

    Dear all,
    
    We are working on a DOTS draft about using the Hop-by-Hop option header
    to encapsulated DDoS signaling  within network to enabel a kind of
    epidemic propagation
    (https://tools.ietf.org/html/draft-francois-dots-ipv6-signal-option-01)
    
    Some comments have been raised considering the real use of the
    Hop-by-Hop option. We would like to ask you your feedback about using it
    for very specific signaling among trusted parties. In particular, do you
    know any reference to a particular use of Hop-by-Hop in a real case.
    
    We have also followed the mailing list discussion about header insertion,
    which obviously concerns our approach since we are extracting and inserting
    some info in headers on the paths. Even if this is is limited to specific 
    routers in a single domain, we understand that it can create problems and
    should maybe use packet encapsulation.
    
    Best regards,
    
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------