[trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Wed, 05 July 2017 11:38 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: trill@ietf.org
Delivered-To: trill@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8FF129B94; Wed, 5 Jul 2017 04:38:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-trill-arp-optimization@ietf.org, trill-chairs@ietf.org, skh@ndzh.com, trill@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.55.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149925473455.19397.5891341140635090367.idtracker@ietfa.amsl.com>
Date: Wed, 05 Jul 2017 04:38:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/5AFlOAoTlYg2C1AlrhEGzShrayA>
Subject: [trill] Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: (with DISCUSS and COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 11:38:55 -0000
Eric Rescorla has entered the following ballot position for draft-ietf-trill-arp-optimization-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-arp-optimization/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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. This document seems very sketchy on what you do when you get duplicate IPs. 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? What do you reply to ARPs with and/or propagate to other nodes? Do you tell the originator of the advertisement you have a duplicate? 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. In general, the security considerations need a complete threat analysis per 3552. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? 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. 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. 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. S 8. some other location (MAC/VM Mobility) and gets connected to egde- Nit: edge is mispelled.
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Donald Eastlake
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Donald Eastlake
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- [trill] Eric Rescorla's Discuss on draft-ietf-tri… Eric Rescorla
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Susan Hares
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Susan Hares
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Donald Eastlake
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Donald Eastlake
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Donald Eastlake
- Re: [trill] Eric Rescorla's Discuss on draft-ietf… Eric Rescorla