Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Warren Kumari <> Mon, 09 December 2019 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47554120113 for <>; Mon, 9 Dec 2019 14:56:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vqwtCRUOfBdg for <>; Mon, 9 Dec 2019 14:56:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 436B812018B for <>; Mon, 9 Dec 2019 14:56:10 -0800 (PST)
Received: by with SMTP id m188so14757167qkc.4 for <>; Mon, 09 Dec 2019 14:56:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oX+8Z1UqSUugy795OysjLyhaX1/Unln6emhgpqkhu/M=; b=iIIhLxI+yPbU1iZy/5rI51TKpHckJzOk386/8iebfC+S4SrninzVszx3prvO43iYC6 OMx82OZ8j7rq9tAIY8/NhJNz4wSCvpXr3+lj9JwPefqr4Yoxd8hHydcA1N1v23CUZMad KNwfVjxssaVpe2qsbDUJXeRvriiVYfHLTvX3SmXsKjvWVfGZLHYr5Bbbw8LLe09c8C4g FBITS7NcN2X7HVdg+Paz1euN8Xx+lEceI/ZZU9yHDRcuE/3IoOQdfXvFZnrBfxLkXxen IvqfHnxQI+4lRlH+t3WYlv3xxvdiUmfV/89iZfUsA1jfoPrSNhhUk3PJjDW+DGZf7Zry 53Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oX+8Z1UqSUugy795OysjLyhaX1/Unln6emhgpqkhu/M=; b=Y/Ah2MvybosAgepdHfgDNtWESTxa3jEemxBAmAjxW3+oh6BS1jGMdPpVT4ECsThevs I5iV8gt82fIUUH2uwbsWW8SRafMIEGOc53/zmrz0KwIw/ePluxvB9H+Gjai6/x/cdefe 44BeuGdYTjgxFJMZKGW1I2YDg9DcUP9/1etrxy6ffKan7rXpWPIpbCKiYKTlbCGo5meP 4ASFFWxcVEn1WNdeGiOy21KkfxYe7AOeVkRp0DqhSJJwO0fgqHsax/bfRPcwI7mIPObZ 4rf4mFKI+7DEgkqJEanMkyHHIDkhrFLRNZmAJMSP387kzQPKxPGKQCsRPTL8EumOMyru quzA==
X-Gm-Message-State: APjAAAX/6DYMQ6/cTFBJcP27FkPsocxUqwVlifODYhsWjNZ4cMY99CZh lwn5j+yI/5W9LNwwV1U7TfGCOhRtv1ZFA/o/7rQDqA==
X-Google-Smtp-Source: APXvYqyOMlCzpQOyBDu5sU8pRefpZO+Ou7H8Rt8LZIG5aoPjLYVOQxAdOcrUg+lfYzAnrKvRihfM/fUizVyaPyJdIcU=
X-Received: by 2002:a05:620a:15d0:: with SMTP id o16mr29242623qkm.106.1575932167906; Mon, 09 Dec 2019 14:56:07 -0800 (PST)
MIME-Version: 1.0
References: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <17421_1575566127_5DE93B2F_17421_93_1_53C29892C857584299CBF5D05346208A48D1A3DA@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Warren Kumari <>
Date: Mon, 9 Dec 2019 17:55:31 -0500
Message-ID: <>
To: Bruno Decraene <>
Cc: SPRING WG List <>, "" <>, draft-ietf-spring-srv6-network-programming <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Dec 2019 22:56:13 -0000

<no hats>

On Thu, Dec 5, 2019 at 12:15 PM <> wrote:
> Hello SPRING,
> This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1].
> Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20.

I will happily admit that I haven't been following the discussions, so
apologies in advance - I'm guessing I'm missing something really
obvious, so please point me at other documents / email threads where
this has already been answered...

RFC5095 deprecated IPv6 RH0 due to some serious security issues - it
was possible for an attacker to send traffic containing "instructions"
to make a packet ping-pong between two interfaces, steer it down
specific links, etc.

It feels to me like this re-introduces similar (and potentially more
scary) issues -- what's to stop an attacker spoofing traffic
containing a bunch of SIDs which decapsulate, push a packet into
another FIB, End.DT2M, etc?

I went to look in the Security Considerations section, but, well, the
document doesn't seem to have one?...
The word Security appears 3 times in the document - one in the section
title ("7. Basic security for intra-domain deployment"), once in the
Index, and once simply punting the reader to Section 5.1 of the SRH
document ("Future documents will detail inter-domain security
mechanisms for
 SRv6 ").

Expecting *everyone* who deploys this to perfectly apply filters which
blocks ingress traffic everywhere where a packet could enter a domain
feels like an accident just waiting to happen
Again, I'm guessing that I'm missing something obvious, and that the
entire security isn't premised on that - please point me to where this
is addressed.

"With great power comes great responsibility"
    -- sudo, via Peter Parker.


> You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics.
> If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.
> This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions)
> Thank you,
> Bruno
> [1]
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.