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

["Susan Hares" <[e-mail]>]

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:[e-mail]] 

Sent: Wednesday, July 5, 2017 7:39 AM

To: The IESG

Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]

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?   

 

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

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? 

 

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

 

 

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

 

 

 

----------------------------------------------------------------------

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.