Hi Eric, I realize that most of the delay has been on the TRILL WG end but I hope you don't mind if I ping you again on looking at the -09 revision of this draft...
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Mon, Oct 9, 2017 at 7:05 PM, Donald Eastlake <[email protected]> wrote: > Hi Eric, > > A -09 version of draft-ietf-trill-arp-optimization has been posted. Could > you look at it to see if it resolves your comments? > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) > 155 Beaver Street, Milford, MA 01757 USA > [email protected] > > On Mon, Oct 2, 2017 at 2:12 PM, Eric Rescorla <[email protected]> wrote: > >> >> >> On Mon, Oct 2, 2017 at 4:54 PM, Donald Eastlake <[email protected]> wrote: >> >>> 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 <[email protected]> wrote: >>> > >>> > >>> > On Wed, Aug 23, 2017 at 12:38 PM, Donald Eastlake <[email protected]> >>> wrote: >>> >> >>> >> Hi Eric, >>> >> >>> >> On Wed, Jul 5, 2017 at 7:38 AM, Eric Rescorla <[email protected]> wrote: >>> >> > Eric Rescorla has entered the following ballot position for >>> >> > draft-ietf-trill-arp-optimization-08: Discuss >>> >> > >>> >> > ------------------------------------------------------------ >>> ---------- >>> >> > 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. >>> >> >> I think if you just sort of say "you are using it, but it's not >> trustworthy and here's why" you have it covered. >> >> -Ekr >> >> >>> >> > 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". >>> >>> OK. >>> >>> >> > 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. >>> >>> OK. >>> >>> >> > 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. >>> >>> >> > ------------------------------------------------------------ >>> ---------- >>> >> > COMMENT: >>> >> > ------------------------------------------------------------ >>> ---------- >>> >> >>> >> 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 >>> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA&entry=gmail&source=g> >>> >> [email protected] >>> >> >>> >> > 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 >>> > >>> > LGTM >>> > >>> > >>> >> > 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. >>> >>> Thanks, >>> Donald >>> =============================== >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA >>> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA&entry=gmail&source=g> >>> [email protected] >>> >> >> >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
