Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt

Patrick McManus <mcmanus@ducksong.com> Wed, 11 March 2015 14:52 UTC

Return-Path: <mcmanus@ducksong.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EDE1AC41D for <spud@ietfa.amsl.com>; Wed, 11 Mar 2015 07:52:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
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 8mJHAI3XRxiT for <spud@ietfa.amsl.com>; Wed, 11 Mar 2015 07:52:39 -0700 (PDT)
Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id E3AAA1A88E6 for <spud@ietf.org>; Wed, 11 Mar 2015 07:52:38 -0700 (PDT)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id 46EEA3A022 for <spud@ietf.org>; Wed, 11 Mar 2015 10:52:33 -0400 (EDT)
Received: by qcwb13 with SMTP id b13so10731670qcw.9 for <spud@ietf.org>; Wed, 11 Mar 2015 07:52:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.80.213 with SMTP id c79mr46070612qgd.74.1426085547942; Wed, 11 Mar 2015 07:52:27 -0700 (PDT)
Received: by 10.140.104.115 with HTTP; Wed, 11 Mar 2015 07:52:27 -0700 (PDT)
In-Reply-To: <75723F2D-969C-4FBF-81D9-20EC106951EC@trammell.ch>
References: <20150303155825.32731.37010.idtracker@ietfa.amsl.com> <08728A73-ED15-4928-A5BB-A59EA9E6D785@cisco.com> <CA+9kkMDSMMUByAMOc8gSyMajyKj0ZtZzmFPg+J7bz-6AYkFYhw@mail.gmail.com> <CAOdDvNrRcMCnWMzBvL0Do16mmiajeR4OJRx36cxnppuaD7+81w@mail.gmail.com> <C0A46E88-A9C2-4EB3-B7B6-2DE20D0B957A@cisco.com> <CA+9kkMDaWrvZM3b7G8FyuiHL0nRO=kWLHjqxQjPjxqtoa1Dq=w@mail.gmail.com> <CAOdDvNq3NMP6ynqXmfoaVStFpRjVq70ZupVqt6ZmZutdg96SaA@mail.gmail.com> <6DC4AC2F-7279-4B18-8656-939E787E055D@trammell.ch> <5F294E01-B194-4969-8603-671D57569637@cisco.com> <A5F41169-7BB9-4F6D-8978-356A65E6093B@in-panik.de> <75723F2D-969C-4FBF-81D9-20EC106951EC@trammell.ch>
Date: Wed, 11 Mar 2015 10:52:27 -0400
Message-ID: <CAOdDvNqLPOB1DgNWJg5PsCN+bBmeeBs76dEt-XFU3UxzqYba5A@mail.gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
To: Brian Trammell <ietf@trammell.ch>
Content-Type: multipart/alternative; boundary=001a11c120a28128870511046aa5
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/VEhLz-1TXBeqpU-SBYX9Jir8vQQ>
Cc: "Philipp S. Schmidt" <phils@in-panik.de>, Ted Hardie <ted.ietf@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, "Joe Hildebrand \(jhildebr\)" <jhildebr@cisco.com>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] New Version Notification for draft-hildebrand-spud-prototype-02.txt
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2015 14:52:39 -0000

On Wed, Mar 11, 2015 at 9:47 AM, Brian Trammell <ietf@trammell.ch> wrote:

>
> Perhaps we can apply the question that led to the separation of TCP and IP
> in the first place: does the path need to see it / can the path do
> something universally useful with it? Put it in SPUD. Is it end-to-end?
> Stick it above SPUD, encrypt it, and hide the key from the path.
>
>
I like that as a guiding principle


> Put that way, session IDs binding flows together seem to me to be an
> end-to-end thing. But of course different situations might have different
> requirements.
>
>
I feel like the sticky part here is that middle boxes on the paths are
playing a role here where the information can be useful.. in particular
without this information they aren't able to route e2e based on just 5
tuple because of the nat/firewall translations they do.