Re: [secdir] Secdir review of draft-ietf-savi-send-10

[Alberto García <[e-mail]>]

Hi Vincent,

I think there is a single issue left to solve in this email, which I comment
in brown color.

 

 

De: Vincent Roca [mailto:[e-mail]] 
Enviado el: viernes, 10 de enero de 2014 15:49
Para: Alberto García
CC: Vincent Roca; 'IESG'; [e-mail];
[e-mail]
Asunto: Re: Secdir review of draft-ietf-savi-send-10

 

Hello Alberto,

 

This i-d contains a detailed Security Consideration sections which is great.

However I have a few questions and comments.

 

1/ Section 5 says:

   "The interaction in a mixed scenario comprising SEND and non-SEND

   devices should be addressed in other document."

What happens if an attacker behaves as a non-SEND host? Is it sufficient

to escape SEND SAVI and launch an attack? This is not said.

 

Yes, this is not said and it should. I have modified the first paragraph to
say:

 

   SEND SAVI operates only with validated SEND messages.  Note that IPv6

   packets generated by non-SEND nodes will be discarded by the first

   SEND SAVI device receiving it.  Therefore, attackers cannot obtain

   any benefit by not using SEND.  In order to perform address

   validation in a mixed scenario comprising SEND and non-SEND devices,

   a different solution is required, which should be addressed in other

    document.

 

VR: perfect.

 





2/ Section 5.2 says:

   "The recommended minimum

   is the memory needed to store 4 bindings associated to the port."

If there are several hosts behind this port (e.g., several hosts behind a
hub

attached to this switch, or several virtual machines), this value of 4 may
not

be sufficient. I agree that having per-port buffers is fine, but specifying
a

value is risky.

 

This text is also included in RFC 6620 (FCFS SAVI)

Note that the value specified is a *minimum*, which means that

-        Implementors of SEND SAVI devices could raise this number, of
course, probably depending on the memory they have.

-        This is the minimum in case malicious nodes are connected to other
ports trying to exhaust memory; i.e., there will always be at least 4
bindings, which should be a minimum number of addresses for one basic host
(link local address + global unicast address…). Even if this is the minimum
being set, when an attack is not occurring more than 4 bindings could be
available to certain ports, assuming that the device can store more bindings
than 4*number_of_ports.

 

In order to stress the first idea, I have rephrased the paragraph as
follows:

 

   The recommended minimum
   is the memory needed to store four bindings associated to the port,
   although it should be raised if the ratio between the maximum number
   of bindings allowed in the device and the number of ports is high.

 

VR: I understand that this is a minimum, but don't you think that because a
value is mentioned, there is a risk?

In the new text, you're saying: "it should be raised if...". First of all,
it's better to use RFC2119 keywords. Then

why do you say "should"? I'd rather say "MUST" since there is no choice in
that case.

 

ALB: I think that if we include a MUST, then we should be much more precise
on how this minimum is computed as a function of the maximum number of
bindings and the number of ports. And I don’t think this must be specified. 

I agree that use of RFC2119 keywords MUST be improved, so I have rephrased
again as:

 

   In addition, it is also RECOMMENDED that a SEND SAVI device reserves

   a minimum amount of memory for each available port (in the case where

   the port is used as part of the L2 anchor).  The REQUIRED minimum is

   the memory needed to store four bindings associated to the port,

   although it SHOULD be raised if the ratio between the maximum number

   of bindings allowed in the device and the number of ports is high.

 

Do you think this is acceptable?

 

Regards,

Alberto





By the way, you raise an interesting issue that has not been considered in
the previous versions of the document: the virtual machine case. In order to
address this, at least cursorily, I have included the following text in
section 2.4 ‘Special Cases’:

 

   Virtual switches: A hypervisor or a host Operating System may perform
   bridging functions between virtual hosts running on the same machine.
   The hypervisor or host OS may in turn connect to a SEND SAVI system.
   This scenario is depicted in the next figure, with two virtual
   machines VM1 and VM2 connected through a virtual switch VS1 to SEND
   SAVI device SEND-SAVI1.  The attachment points of VS1 to VM1 and VM2
   are configured as Validating.
 
 
       Host1
       +----------------+
       | +---+   +---+  |
       | |VM1|   |VM2|  |
       | +---+   +---+  |
       |   |     |      |
       | +-1-----2--+   |
       | |   VS1    |   |
       | +--3-------+   |
       |    |           |
       +----|-----------+
            |
            |
         +--1-----2--+
         |   SEND-   |
         |   SAVI1   |
         +--3---4----+
            |   |
 
 
 
   In order to provide proper security against replay attacks, it is
   recommended to perform SEND SAVI filtering as close to untrusted
   hosts as possible (see Section 3.4 and Section 5.1).  In this
   scenario, this objective can be achieved by enabling SEND SAVI
   validation in VS1.  Ideally, VS1 could be integrated into the SEND
   SAVI protection perimeter, if the hypervisor or host OS at Host1 can
   be trusted (even though VM1 and VM2 could not be trusted).  To do so,
   both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1,
   are configured as Trusted.
 
   If the administrator of the network does not trust on VS1, port 1 of
   SEND-SAVI1 is configured as Validating, so that every address being
   used at Host1 is validated at SEND-SAVI1 by SEND SAVI.  The
   attachment point to the physical network at VS1 should be configured
   as Trusted, if the host administrator knows that it is connected to a
   SEND SAVI device; in this case, VS1 relies on the infrastructure
   comprised by the physical SEND SAVI devices, but not the other way.
   Packets egressing from VM1 are validated twice, first at VS1, and
   then at SEND-SAVI1; packets going in the reverse direction (from an
   external host to VM1) are validated once, when they first reach a
   SEND SAVI device.  If the administrator of VS1 does not trust on the
   physical switch to which it attaches, it can configure the attachment
   to SEND-SAVI1 as Validating.  In the figure above, this means that a
   packet going from another host to VM1 would be validated twice, once
   when entering the SEND SAVI perimeter formed by the physical devices,
   and the other when entering at VS1.

 

 

 

 

3/ Section 5.2 is a bit confusing and I'm wondering if it could not be
simplified.

 

Just to provide some background about this section: it is almost the same
text as section 4.1 of RFC 6620, since the DoS problems are mostly the same
(except for the last paragraph of the section, which insists in the extra
cost of cryptographic operations due to the use of SEND.

This being said, I do not pretend that RFC6620 text could not be improved.

 

VR: It makes sense to borrow text from previous documents, but improving it
makes sense too.

Anyway, the only think that matters is the result.

 

 

Basically, it says:

- in case of memory shortage, it is RECOMMENDED to "delete the entries with

  a higher Creation time".

  BTW, what do you mean by "higher creation time"? The oldest entries el?

 
 
No, the newer ones, as the next sentence clarifies: ‘This implies that older
entries are preserved and newer entries overwrite each other. 

 

VR: The new text is much better and avoids any misunderstanding.

 





- it is RECOMMENDED to reserve some memory for each port in order to isolate

  the effects to the attacker's port;

- one MUST limit the maximum amount of memory used to store data packets

  in order to keep memory for other tasks;

- one SHOULD rate limit packets which may trigger SEND SAVI events, since

  it requires costly crypto operations.

  BTW, why do you say "which may trigger" instead of "which trigger"?

I remove ‘may’.

Your summary is correct.

 

 

Third paragraph is strange.

 

According to your comments, I have changed the text to (I explain later the
changes):

   The SEND SAVI device may store data packets while the address is
   being verified, for example, when a DAD_NSOL was lost before arriving
   to the SEND SAVI device to which the host attaches, and the host
   sends data packets, these data packets may be stored until the SEND
   SAVI device verifies the binding by means of a NUD packet exchange.
   In this case, the memory for data packet storage may also be a target
   of DoS attacks.  A SEND SAVI device MUST limit the amount of memory
   used to store data packets, allowing the other functions (such as
   being able to store new bindings) to have available memory even in
   the case of an attacks such those described above.
 

 

 

 

I read:

   "As the SEND SAVI device may store data packets while the address is

   being verified..."

If the incoming packet rate is higher than the packet verification rate,
sure

there will be problems. Is it what the authors mean? I don't see any good

solution except rate limiting the incoming packet flow.

 

I think it was not clear enough the case to which we were referring. That’s
why I changed the first sentence.

What I want to note is that this is a particular case, but not ‘normal
operation’ of the SAVI device, because in most cases (well-behaved hosts),
DAD_NSOL is going to be issued first, and the host will not send packets
until the address is valid (and so the state at the SEND SAVI devices).

However, we do not want malicious nodes to exploit the fact that memory
(especially for other more relevant uses, such as storing bindings) could be
exhausted in this way.

 

VR: agreed.

 





Later:

   "The effects of such attacks may be limited to

   the lack of capacity to store new data packets."

          Does it mean that setting an upper limit to the amount of memory
devoted

to store data packets is a way to mitigate the attack (last sentence),

or does it mean that the attack will lead packets to be dropped (following

sentence)?

 

I agree that the two sentences starting by the one you copy here were hard
to understand. As you see in the new version of the text (above), I have
removed them. What I think is the most relevant problem is that using memory
for this could drain resources for other functions, and this is stated in
the last sentence.

 

VR: okay.

 





And when it is said that:

   "A SEND SAVI device MUST limit the amount of

   memory used to store data packets, allowing the other functions to

   have available memory even in the case of an attacks..."

What do you mean by "other functions"? SEND SAVI functions? Others?

I have clarified this in the text

 

5/ Section 5.4 says that "a SEND SAVI MUST NOT log binding anchor
information

except [if there's a good reason for that]". And later that "information
about

the majority of hosts that never spoof SHOULD NOT be logged."

 

The intention is fine, but if I understand correctly, SAVI requires to
identify

a host's legitimate IP source addresses (RFC 7039). It means that this
information

will be logged any away as SAVI needs it (if I understand correctly).

Or may be by "logging" you mean "long term logging" but in that case this is

not clear. Or is there something else I've missed?

 

You are right. I have changed this to

 

   A SEND SAVI device MUST delete binding anchor information as soon as
   possible (i.e., as soon as the state for a given address is back to
   NO_BIND), except where there is an identified reason why that
   information is likely to be involved in detection, prevention or
   tracing of actual source address spoofing.  Information about the
   majority of hosts that never spoof SHOULD NOT be logged.

 

 

VR: okay

 





Typos:

 

** s/reply/replay  in:

   "There are two different cases to analyze when considering SEND SAVI

   reply attacks:"

 

** s/In this two cases/In these two cases/

 

** s/messages which does not result in changes/messages which do not result
in changes/

 

** s/in the case of an attacks such those described above/in the case of an
attack like the one described above/

 

Corrected!

Thanks again for your comments

 

You're welcome.

Cheers,

 

   Vincent