Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT)

Donald Eastlake <> Mon, 02 October 2017 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A5F612421A; Mon, 2 Oct 2017 09:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4z2YKDLZSaJ6; Mon, 2 Oct 2017 09:54:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2A87133052; Mon, 2 Oct 2017 09:54:30 -0700 (PDT)
Received: by with SMTP id s145so4268618oie.1; Mon, 02 Oct 2017 09:54:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q5uHCOUHdo400h0VwczK5/d7/o/DczQ8RrTKnoutRxg=; b=Al+tBDgM2yoGeMGSfiR65zK2XKaCa1OjE3KJP0YwC/AwhbUnS/G3G9gA5fbmkriz2B xz5/+DbYqLYoTDJcuRthw8rUuh7zMS6VYfVWChV2dD4JTsN7nfRosOSOmhhgcoPQprUW tGkeGMoXkcmwAaCupPHf7ih+8wh4ul039eU7tvO5fT7JVamqVUxofTy7Y/1QBgZ6tJlJ Mwon2RMz6BebXDMkzN7vrfIi6DxO/PKL0KwLRD0YYFjfBHU0vpEQ0GkGlvcZ1vcJoBTa ncm9129ucPDAs3se2jVmyD9h0yw/+ond9UvQadpwroDb8qtnae1kqjJ6QIVrUx+VvCrY 3VNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q5uHCOUHdo400h0VwczK5/d7/o/DczQ8RrTKnoutRxg=; b=J4UOiSgh93oQ8tl7BwCuZ4dNR6EDfJNVbxqJQ6L6VL/De7gr4KO+WfErb2wwXpZpZW oSYhjnFx6OOej7HsiAMbiEAzWWF2u87d8dlUQO9xjgWIXw0XI/8MgHwO8Vln50R/QbnQ 8+YJb9kfmjje9JSwLt0826JSgmLpJ+xr8DFgZmC+fVNuFlnx3ibtR9PMmQEK9hhNPlmT gU03XTznjstMB9f1ugiRLDdkDuDHO9Iijh4dHcydI6tyk8yfoTOXAmRI3Zd6H0nNP8lt X62EMsFiAyY6DfmmPAZesx7vKXFHCoFS8YNFHV6NEVOxWap1Xx+ZjtPKgSfSXr/fZbgE tMIA==
X-Gm-Message-State: AMCzsaVbu+RflX/Afz8t1h8vQD0LEFHQvn13hbsKe9wuPG0fFDBTlmF8 qeiVx2ckIV4qqW/pgAkKzkzVwfWg4pZ/FD2XzqAM9B+2
X-Google-Smtp-Source: AOwi7QATNEpzNCUgyMpVHKsZUCVRwHtFhKzCAW07Hsp9z88v45expkWxIQB9FbuuIdIrGYlzq4TBvQ3UI2z+hI+oUkc=
X-Received: by with SMTP id h123mr6450137oib.106.1506963269665; Mon, 02 Oct 2017 09:54:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 2 Oct 2017 09:54:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Donald Eastlake <>
Date: Mon, 02 Oct 2017 12:54:14 -0400
Message-ID: <>
To: Eric Rescorla <>
Cc: The IESG <>,, "" <>, Susan Hares <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Oct 2017 16:54:35 -0000

Hi Eric,

My apologies for the delay in response. (For part of the time I was on
a cruise...)

It looks like we are in agreement on most items.

See below.

On Fri, Sep 22, 2017 at 9:18 AM, Eric Rescorla <> wrote:
> On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake <> wrote:
>> Hi Eric,
>> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla <> wrote:
>> > Eric Rescorla has entered the following ballot position for
>> > draft-ietf-trill-arp-optimization-08: Discuss
>> >
>> > ----------------------------------------------------------------------
>> > ----------------------------------------------------------------------
>> As a general comment, the Security Consideration section could use
>> clarification and some expansion.
>> Although one can imagine various mixed modes, to the first approximation
>> there are two ways of doing the optimization of various multi-destination
>> messages discussed in this document:
>> + Using data plane learning by observing ARP/ND and similar messages (in
>> addition to the learning of MAC addresses from the data plane which is
>> enabled by default in TRILL). As described in this document, such data plane
>> learning by TRILL switches can be used to sometimes optimize
>> ARP/ND/RARP/unknown-destination messages. But the result isn't particularly
>> more or less secure than it is when this data plane learning is done by end
>> stations rather than by TRILL switches (or bridges or other kinds of
>> switches) in the middle doing some optimization of the relevant
>> multi-destination messages. Interface address information learned through
>> data plane learning by edge TRILL switches can also be propagated via the
>> control plane but this is not significantly different from propagating that
>> information via the multi-destination messages that are being optimized to
>> unicast or optimized away.
>> + Using a complete, trusted directory as might be based on an orchestration
>> system in a data center. Since the messages between TRILL switches doing
>> ARP/ND/RARP/unknown-destination optimization can be secured and the TRILL
>> switches can be configured to ignore data plane learning, this enables TRILL
>> switches to provide answers that are "correct" in that they correspond to
>> the data in this complete, trusted directory. However, there can still be
>> various forged messages/addresses on a local link between end station(s) and
>> edge TRILL switches. Such a local link can, with TRILL, be a bridged LAN, so
>> such forgeries emitted by an end station may be seen by other end stations
>> and cause incorrect learning from the data plane.
>> The existing Security Considerations section is a bit sketchy and
>> concentrates more on the data plane case, as that is the one with the
>> greatest security challenges.
> Yes, this seems like a reasonable assessment. Alia, does someone have the
> action item to make it less sketchy?

We are working on a draft revision to reflect the above thinking to a
greater extent and decrease sketchiness.

>> > It's not clear to me how the security properties of this mechanism
>> > compare to existing TRILL. The text says:
>> >
>> >    Unless Secure ND (SEND [RFC3971]) is used, ARP and ND messages can be
>> >    easily forged. Therefore the learning of MAC/IP addresses by RBridges
>> >    from ARP/ND should not be considered as reliable. See Section 4.1 for
>> >    SEND Considerations.
>> >
>> > "not considered as reliable" seems suboptimal. You need to cover how
>> > this mechanism compares to the non-use of this mechanism.
>> As above, the optimization mechanisms do not make any significant
>> difference to the inherent insecurities of data plane learning but when used
>> with a complete, trusted directory, it improves considerably over data plane
>> learning..
> That had kind of been my impression, but then I don't understand what "not
> considered as reliable" is doing here. I'm supposed to be doing something
> with it, so while it may be non-secure, I'm still relying on it, no?

Well, at some level some elements of your protocol stack are "relying"
on it or "trusting" it or whatever term you want, but it's trivially
forged unless you use additional security protocols so I guess we
could say something about that. TRILL supports different link
technologies but if you are using an Ethernet link, I suppose you
could use 802.1AE to improve trust in MAC addresses at layer 2. It
wouldn't hurt to mention that but it has very little to do with ARP/ND
optimization or TRILL.

>> > This document seems very sketchy on what you do when you get duplicate
>> > IPs.
>> Why should what you do when you notice a duplicate IP address be
>> significantly different just because some multi-destination messages are
>> being optimized? Why shouldn't you just do whatever you do now and why is
>> that any of TRILL's business?
> Because you're getting the information via different vector, TRILL needs to
> specify what you do,
> if only to say "do what you would do otherwise".


>> >    In the case where the former owner replies, a Duplicate Address has
>> >    been detected. In this case the querying RBridge SHOULD log the
>> >    duplicate so that the network administrator can take appropriate
>> >    action.
>> >
>> > How does logging solve the problem?
>> It doesn't but it seems better than not logging.
>> > What do you reply to ARPs with and/or propagate to other nodes?
>> If you are asking how you reply to ARPs if the IP address being ARPed for
>> has been found to be duplicated, there are the two cases outlined above. If
>> you are using a complete, trusted directory, you give the presumed correct
>> answer provided by that directory. If you are using data plane learning, you
>> use whatever you last learned from the data plane (which could have been a
>> forgery over writing good information or good information over writing a
>> forgery or a forgery overwriting a different forgery or ...).
>> > Do you tell the originator of the advertisement you have a duplicate?
>> As far as I know there is no standardized way to tell a station that you
>> think it has an IP address that is duplicated locally and I don't think it
>> is the job of TRILL to provide such a mechanism. Certainly this document
>> does not propose anything of that sort.
> OK.
>> >    When a newly connected end-station exchanges messages with a DHCP
>> >    [RFC2131] server an edge RBridge should snoop them (mainly the
>> >    DHCPAck message) and store IP/MAC mapping information in its ARP/ND
>> >    cache and should also send the information out through the TRILL
>> >    control plane using ESADI.
>> >
>> > What happens if the attacker sets up a fake DHCP server and pretends
>> > to assign addresses to himself? It seems like maybe that's the same
>> > as fake ARPs but maybe not.
>> This snooping on DHCP messages only applies to the data plane learning
>> case. In the case of a complete, trusted directory, edge RBridges already
>> know the right answer, so to speak. With data plane learning, if there are
>> forged DHCP messages, things are likely to get all screwed up. Of course,
>> you could run DHCP over IPsec but, partly due to the localized nature of
>> DHCP, I don't think very many people do that. There is also RFC 3118 which
>> can be used to authenticate DHCP messages, but that assumes the distribution
>> of keying information.
>> There isn't much difference between the various multi-destination messages
>> (ARP / DHCP) advertising the addresses and point of attachment of
>> interfaces. But, overall, I'm not sure why a document that is just
>> describing ways to optimize the distribution of various multi-destination
>> messages needs to analyze the security of the protocols implemented by those
>> multi-destination when, as in the data plane learning case, it is not
>> significantly changing that security.
> Well, in this case, you have a new threat vector: DHCP. Even if it is the
> same kind of threats, it's still a new threat vector.
> More generally documents need to contain complete security considerations
> sections. If the security considerations
> are the same as with some other document, then they need to say that.


>> > In general, the security considerations need a complete threat
>> > analysis per 3552.
>> I don't think there is that much new in this document. While the Security
>> Considerations section needs clarification and some expansion, I don't think
>> it is, for example, the job of this document to do a threat analysis of the
>> ARP protocol as long as it can make a reasonable case that the security of
>> ARP is not significantly changed by the optimizations specified.
> Sure, but it also doesn't make that case.

I'll see what we can do.

>> > ----------------------------------------------------------------------
>> > ----------------------------------------------------------------------
>> For completeness, I've cut and pasted below the COMMENT responses I sent
>> to you a while ago.
>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>> > S 2.
>> >
>> >    plane on the edge RBridges, it should be possible to completely
>> >    suppress flooding of ARP/ND messages in a TRILL Campus, When all end-
>> >    station MAC addresses are similarly known, it should be possible to
>> >    suppress unknown unicast flooding by dropping any unknown unicast
>> >    received at an edge RBridge.
>> >
>> > Are these "should be possibles" normative? Descriptive?
>> Section 2 of this document is a general discussion of the optimization
>> problem which, while it does mention a couple of possible facets of
>> potential solutions, is not intended to be normative.
>> > S 4.
>> > This is a sequence of steps, so it would be nice to preface them with
>> > a list of the steps. It's also odd to have SEND considerations right
>> > in the middle here.
>> Sorry, I don't understand exactly what you are pointing at as a
>> sequence of steps. All of Section 4? Just the text between the Section
>> 4 heading and the Section 4.1 heading? Something else?
> Sorry, my point is that if I read this correctly, I do 4.3, then 4.4, etc.
> It would be nice if they were listed ahead of this as "this is what you do,
> now read the sections"

OK. We can add some clarifying material to Section 4 before the 4.1 heading.

>> > 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP
>> >
>> > Please explain what a non-zero IP is and why it's relevant.
>> > This graf also needs an introductory sentence or something before
>> > the bullets.
>> Here is a copy of the response that was sent to a similar comment in
>> Dale Worley's GENART review:
>> This section is talking about getting and handling the IP/MAC
>> mapping information for a local end station by an edge RBridge. An
>> ARP/ND from such a local end station might show a zero source IP
>> address if the end station does not have one or is probing for
>> duplicates.
>> Perhaps the title for the Section should be something like
>>    4.3 Extracting Local End Station IP/MAC Mapping Information
>> and a new first paragraph could be added something like
>>    Edge RBridges extract and use information about the correspondence
>> between local end station IP and MAC addresses from the ARP/ND
>> messages those end stations send as described below. An apparent zero
>> source IP address means that the end station is probing for duplicate
>> IP addresses and messages with such a zero source IP address are not
>> used for the extraction of IP/MAC address mapping information
>> > S 4.4.
>> >    It is not essential that all RBridges use the same strategy for which
>> >    option to select for a particular ARP/ND query. It is up to the
>> >    implementation.
>> >
>> > This seems inconsistent with the MUST in arm (b) below, because I
>> > can just take some other arm. It's also kind of surprising to be this
>> > non-prescriptive.
>> The wording needs to be clarified. Which lettered item listed below
>> applies is determined by the circumstances; however, which of the
>> numbered strategies associated with these items is followed is an
>> implementation choice in handeling any particular ARP/ND.
> OK.
>> > S 8.
>> >    some other location (MAC/VM Mobility) and gets connected to egde-
>> >
>> > Nit: edge is mispelled.
>> OK.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA