Re: [Status] Charter security text

Robert Raszuk <robert@raszuk.net> Thu, 10 October 2013 15:53 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79A121E8056 for <status@ietfa.amsl.com>; Thu, 10 Oct 2013 08:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCw0+HGc-VJJ for <status@ietfa.amsl.com>; Thu, 10 Oct 2013 08:53:38 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1E70B21E812F for <status@ietf.org>; Thu, 10 Oct 2013 08:53:38 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id x13so5588404ief.1 for <status@ietf.org>; Thu, 10 Oct 2013 08:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wmSVULC023ZesPEtVkLWHd3/NzwqfYsBGfgsl1brEZs=; b=vxy+fKnQt7OM+63vkrC6AJuv8af0Fl31Um494kYt8nbacxuYvROwLno/Z2T5gfu/lg 5sXy0OLkdCoCcfQbhybchHXYtNNYvc9M26H6PNP53L8ptSlfrTM9jKSvWGTVgfvBhb+v 6bocDUKXXLcx/wFbWkYxnrcV6qKIDXRgX4WiOTfy/nLCO9wLoWxdwDEryULb3iy+VpRe qFXvi7LP1N/5iBtqJ4E41NBr8F7MBtLKUUMEjtIu/+uqekrJKCa81iDKm6gr69VSTkmE WfoV2xG86iEl9ymZhvgwfNrUjJEwBpwberBTkhQfwXXwdZEb3wRMKmv+Oe1v1IWZjn1I j4mg==
MIME-Version: 1.0
X-Received: by 10.42.46.80 with SMTP id j16mr728063icf.94.1381420417532; Thu, 10 Oct 2013 08:53:37 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Thu, 10 Oct 2013 08:53:37 -0700 (PDT)
In-Reply-To: <52569169.20404@cisco.com>
References: <52569169.20404@cisco.com>
Date: Thu, 10 Oct 2013 17:53:37 +0200
X-Google-Sender-Auth: WciMSkLzoTaGhInqKzJ6aRkujOg
Message-ID: <CA+b+ERmj13sz4yi+aQXwGKuu7boOKkz6CbcB9pYXqHV-_FMhSw@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: "stbryant@cisco.com" <stbryant@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "status@ietf.org" <status@ietf.org>
Subject: Re: [Status] Charter security text
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/status>, <mailto:status-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/status>
List-Post: <mailto:status@ietf.org>
List-Help: <mailto:status-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/status>, <mailto:status-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Oct 2013 15:53:39 -0000

All,

On the topic of MPLS vs IPv6 - one being L2 hence more secure then the
other (L3) I would like to observe that any decently managed network
would already today prohibit to accept any external packets which have
as destination an infrastructure address of such network. That is the
basic protection scheme against DOS/DDOS attacks to the
infrastructure.

When such packet is detected it should be dropped - not "stripped from
explicit routes" like the above charter update would tend to suggest.

As some may recall in the past we have been working on automating such
ACLs installation based in internal IGP addresses on all border
routers under same administrative domain within single AS or number of
ASes to ease operational burden. Not sure if all vendors support such
automation today.

I think what needs to be understood that segment routing is not
internet wide source routing technology. It is carefully crafted path
engineering and packet encapsulation technique within controlled set
of domains which really do not compare to the original issues and
security concerns of source routing.

Best,
R.


On Thu, Oct 10, 2013 at 1:37 PM, Stewart Bryant <stbryant@cisco.com> wrote:
> SPRINGers
>
> In response to a number of IESG blocking comments I have updated
> the security text in the charter to say:
>
> "There is an assumed trust model such that any node
> imposing an explicit route on a packet is assumed to
> be allowed to do so, however administrative and trust
> boundaries may strip explicit routes from a packet.
> For each data plane technology that SPRING specifies,
> a security analysis must be provided showing how protection
> is provided against an attacker disrupting the network by
> maliciously injecting SPRING packets."
>
> I do not know yet whether this has been accepted.
>
> Stewart
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status