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 (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
