Re: Review of draft-ietf-trill-over-ip-08

Joe Touch <touch@isi.edu> Thu, 05 January 2017 19:01 UTC

Return-Path: <touch@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6468A129625; Thu, 5 Jan 2017 11:01:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10
X-Spam-Level:
X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 L7H6bbrofbc8; Thu, 5 Jan 2017 11:01:22 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1829B129619; Thu, 5 Jan 2017 11:01:22 -0800 (PST)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v05J0uHG008810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2017 11:00:57 -0800 (PST)
Subject: Re: Review of draft-ietf-trill-over-ip-08
To: Donald Eastlake <d3e3e3@gmail.com>
References: <148290260152.14213.11124890517026127285.idtracker@ietfa.amsl.com> <9bbd1c40-a983-e85c-5656-ef17d50b8605@isi.edu> <CAF4+nEFu26=YgZnRnW6rhoObkMWP0g22Rn1jUVv+FtYfBpQk-A@mail.gmail.com> <8ad2471d-e58c-44aa-8ce9-ff814652b10c@isi.edu>
From: Joe Touch <touch@isi.edu>
Message-ID: <78015424-9f4a-2d40-6898-38b02dacc7b9@isi.edu>
Date: Thu, 5 Jan 2017 11:00:57 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <8ad2471d-e58c-44aa-8ce9-ff814652b10c@isi.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/boTtPP4nzU9foW2BRXH1kCilIuE>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "trill@ietf.org" <trill@ietf.org>, IETF Discussion <ietf@ietf.org>, draft-ietf-trill-over-ip.all@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2017 19:01:23 -0000

PS - I have a broader question about this work.

Why is this a service at all?

There are dozens of ways of taking existing IP or Ethernet traffic and
encapsulating them for IP tunnel transit, some including much stronger
protections (e.g. SEAL/AERO provides better fragmentation/reassembly
support).

Why not use one of those existing services?

The only thing this saves is the link header/trailer overhead, but then
it also begs the question of the identity of these tunnel endpoints
within the TRILL system (which are indicated by addresses used in those
link headers).

(if there is an answer to this, it really should be included in the intro)

Joe


On 1/5/2017 10:44 AM, Joe Touch wrote:
> Hi, Donald,
>
>
> On 1/4/2017 5:43 PM, Donald Eastlake wrote:
>> Hi Joe,
>>
>> Thanks for the comments.
>>
>> On Tue, Jan 3, 2017 at 1:56 PM, Joe Touch <touch@isi.edu>; wrote:
>>> - the use of two different ports invites some potentially unintended
>>> problems, e.g., selective blocking of the control vs. data plane. IMO,
>>> given that TRILL's purpose is to extend Ethernet (not IP), this service
>>> would be better served using a single port and differentiated
>>> encapsulated traffic by whatever method TRILL nodes use internally.
>>> Otherwise, this spec needs to include specific description of unexpected
>>> behavior, e.g., data frames on the IS-IS port and IS-IS frames on the
>>> data port.
>> I guess I don't see this.
> It's a configuration issue - what happens when (not if) a sysadmin opens
> up one port but not the other?
>
> IMO, unless there's a reason for that sort of selective filtering or
> there's a specific need to encapsulate the traffic differently, these
> ought to be treated as a single service - TRILL UDP encapsulation.
>
> It's only inside the TRILL system that the difference between data and
> IS-IS is useful and this encapsulation will have no effect on those nodes.
>
>> As for selective blocking, if someone can control the passing of
>> traffic through links connecting TRILL switches, they can always block
>> a subset of traffic based on whatever criteria they want. I don't
>> think it makes significant difference what header field they look at.
> I'm thinking of the increased complexity and potential for failure by
> not "fate sharing" data and IS-IS traffic.
>
>> Similarly, if someone can modify traffic passing through links between
>> TRILL switches, if the traffic is IP they could swap around port
>> numbers, but they could also swap around other header fields.
>> Presumably it is a policy decision for network managers based on their
>> threat model whether or not to use facilities by TRILL or otherwise to
>> provided to secure control traffic and/or use link security to protect
>> all traffic over a link. (Similarly, it is a matter for end system
>> users/managers to decide whether to use end-to-end security.)
> I'm asking whether you actually expect or want IP transit nodes to treat
> data and IS-IS traffic differently - via different routes, different
> drop policies, etc. If not, then there's no benefit from having two
> service ports.
>
>> I suppose we could throw in a few sentences saying that if security is
>> not being used and data or control is mislabeled as the other and it
>> happens to be parseable as the other, you will get junk in the data
>> stream or screwed up control information. 
> TRILL data and IS-IS is already treated differently inside a TRILL
> campus, e.g., by their existing headers. I can't see data being treated
> as IS-IS or vice versa inside the campus, regardless of which port the
> traffic arrives on.
>
> That's largely my point - if the encap/decap node wouldn't need to treat
> these differently in either direction (leaving or entering the TRILL
> campus), then they're one service.
>
>> But I don't think the
>> mislabeling of control and data as the other by TRILL code is a
>> realistic problem. It would be detected by the crudest of testing.
> It *can* be detected, but your protocol needs to specify the correct
> behavior. Is the UDP tunnel ingress/egress supposed to prevent such
> mislabeling on ingress? If so, why would it care? If not, then again
> there's no point to two services.
>
> Joe