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

 

Sue  

 

From: Eric Rescorla [mailto:[e-mail]] 
Sent: Thursday, July 6, 2017 9:06 AM
To: Susan Hares
Cc: The IESG; [e-mail]; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]> 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:[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?  

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.