Re: [Status] SPRING Charter

Robert Raszuk <robert@raszuk.net> Wed, 16 October 2013 18:46 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 2849B11E8147; Wed, 16 Oct 2013 11:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.527
X-Spam-Level:
X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=0.451, 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 BJfxIQi5TO08; Wed, 16 Oct 2013 11:46:12 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 980CB11E8128; Wed, 16 Oct 2013 11:46:12 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id aq17so2021659iec.6 for <multiple recipients>; Wed, 16 Oct 2013 11:46:12 -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:content-transfer-encoding; bh=xRFC8/kBnmr+JxKZ+nqCP9Tw2o6hiF/t3rSYbs4n4pY=; b=gBYcT+aUi/6gg59IV/vzbS8scpbcB0NkoUVAM3lcJ0l8cqCYBeo2fmmWl5hOj8Fy+K DgzNEWf72meHmOFFZULNzWGIwcyzTOxCbHcdfMXZkheeUksSukTPz36W5IeISJj2JMH8 P9Kl3X9a92wNGu0QNG8P49BTJgGqzbZ9jvai0eYI6eOrVQv78QnkdrPQ/L1cfjbpNwSZ zXt7o16iaxCTY8zR/KGY2c16mu/GGR7S5IpGip8GHj9hVh5lCRN0f8bi0XMbeeFnC7v/ 1KJSr20R0ZsTm8fWGbE365f457k4O+MgeOy3cXzPRZOMHHpk7ZMU37UBjdRN7xVRhvJM iGYA==
MIME-Version: 1.0
X-Received: by 10.50.107.102 with SMTP id hb6mr3289431igb.55.1381949172048; Wed, 16 Oct 2013 11:46:12 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Wed, 16 Oct 2013 11:46:11 -0700 (PDT)
In-Reply-To: <AA242DD4-AEE1-465B-8A3C-8887FA1542BB@piuha.net>
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com> <525ECA07.2070207@cisco.com> <9C5D9C4D-F90E-48B3-A005-3DAC1EEC378F@juniper.net> <AA242DD4-AEE1-465B-8A3C-8887FA1542BB@piuha.net>
Date: Wed, 16 Oct 2013 20:46:11 +0200
X-Google-Sender-Auth: PrSYJa6cEyx0TqZxZcRATKdQLEw
Message-ID: <CA+b+ER=P_aBwJMOgbLHgMHceBU=QbMQT=d_A6DRfDroHMR-F-g@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Jari Arkko <jari.arkko@piuha.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "iesg@ietf.org" <iesg@ietf.org>, "status@ietf.org" <status@ietf.org>
Subject: Re: [Status] SPRING Charter
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: Wed, 16 Oct 2013 18:46:13 -0000

Hi Jari,

> And I fear that somewhere down the line someone would decide all we need is
> inside/outside security model, and I do not think that helps enough in this case

For one I am not convinced that inside/outside security model is not
good enough for the problem at hand.

Is your point perhaps more focused towards clear placement of such
boundary ? If so I think it's get more involved indeed as deployment
models may vary. But once such boundary is set I am not sure why it
would not be sufficient for SR architecture.

Specifically we already have defined IGP as the carrier of SIDs. You
normally do not run IGP (passive interfaces excluded) outside of your
domain boundary. That plus ACL towards/against infrastructure
addresses IMHO should provide sufficient isolation.

Best regards,
R.





On Wed, Oct 16, 2013 at 8:38 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
> I'd suggest that the distinction between trusted and non-trusted or host and router is not as useful as we might expect.
>
> What I was trying to suggest with my text was specifying a requirement for a technical mechanism that helps prevent inappropriate headers from being believed. Trusted/non-trusted in itself would not be as useful, until it results in a similar specific requirement. And I fear that somewhere down the line someone would decide all we need is inside/outside security model, and I do not think that helps enough in this case.
>
> But I don't mind the new text if the old text is still also thereā€¦.
>
> Jari
>
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status