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

[Vincent Roca <[e-mail]>]

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.


> 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