On Thu, Jul 6, 2017 at 1:00 PM, Susan Hares <[email protected]> wrote: > Eric: > > > > Thank you for your answers. I will investigate the issues further and > work with the authors to suggest some text. May I or the authors follow up > with additional questions? >
Please. Let me know if I can help, elaborate, etc. -Ekr > > > Sue > > > > *From:* Eric Rescorla [mailto:[email protected]] > *Sent:* Thursday, July 6, 2017 9:06 AM > *To:* Susan Hares > *Cc:* The IESG; [email protected]; > [email protected]; [email protected]; [email protected] > *Subject:* Re: Eric Rescorla's Discuss on > draft-ietf-trill-arp-optimization-08: > (with DISCUSS and COMMENT) > > > > > > > > On Thu, Jul 6, 2017 at 3:06 AM, Susan Hares <[email protected]> wrote: > > Eric: > > > > Thank you for your comments and questions. The text of this email > requests clarification on your discuss so that I may aid the authors in > adjusting the draft. I have included my question inline below. > > > > Sue Hares > > > > -----Original Message----- > > From: Eric Rescorla [mailto:[email protected] <[email protected]>] > > Sent: Wednesday, July 5, 2017 7:39 AM > > To: The IESG > > Cc: [email protected]; [email protected]; > [email protected]; [email protected] > > Subject: Eric Rescorla's Discuss on draft-ietf-trill-arp-optimization-08: > (with DISCUSS and COMMENT) > > > > 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. > > > > Question 1: Are you asking how the "ARP/ND" is unreliable? Is this not > documented adequately in the SEND documentation? > > Are you asking why the learning of MAC/IP addresses by the RBRIDGE using > ARP/ND is not reliable in addition to the issues raised by the SEND > document? > > Sorry, no. I'm saying that "not be considered reliable" is not > operationalizable by > > the implementor. What are they supposed to do with information which is not > > reliable? More specifically, what is their security posture if they use > the mechanism > > documented in this document versus if they do not? > > > > > How does logging solve the problem? > > Question 2: Logging allows the network management systems to detect the > problem, and determine if SEND should be used or if other security measures > should be taken. Are you looking for other mechanisms outside of SEND? > > > > This seems like it's of limited use if this actually is an attack. My > experience > > with logging systems is that people don't check their logs very often > unless > > they see a lot of errors. I've certainly seen duplicate IPs in small > networks > > plenty of times, and I just ignore them. I assume others do as well. > > > > > 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? > > > > Question 3: Are you specifically asking about the reply to duplicate > address detection ARPs in the first question? Are you looking for a > specific answer to second part of this question. In my understanding of > security (which is limited compared to yours), I would not recommend > responding to the originator of the advertisement that there is a duplicate > since this might aid attacks on the valid originator. > > Can you provide additional input on what you'd like to see here? > > I think the spec should take a position on how the implementation should > behave when > > it encounters this situation. My general concern here is that you have a > mechanism > > which has a known security vulnerability but the spec is pretty silent on > how you should > > handle it when you have signs that it is being exploited. > > > > > > > > > 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. > > > > Question 4: Can you provide someone from the SEC-DIR to provide a review > for a threat analysis per RFC3552. > > It's probably easier if I review it. If you're looking for a collaborator, > let me know and I'll see who I can round up. > > > > -Ekr > > > > > > > > > > ---------------------------------------------------------------------- > > 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. > > > > > > >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
