Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB entries?

Hello Pascal,

Yes, it does. Thank you!

Best,
Yatch

> On Jun 21, 2019, at 18:00, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> Hello Yatch;
> 
> In the security section is changed the text to:
> 
> "
> 
> An attacker can perform a Denial-of-Service (DoS) attack on a node implementing VRB by generating a large number of bogus "fragment 1" fragments without sending subsequent fragments.
> This causes the VRB table to fill up. Note that the VRB does not need to remember the full datagram as received so far but only possibly a few octets from the last fragment that could not fit in it.
> It is expected that an implementation protects itself to keep the number of VRBs within capacity, and that old VRBs are protected by a timer of a reasonable duration for the technology and destroyed upon timeout.
> "
> 
> Works?
> 
> Pascal
> 
>> -----Original Message-----
>> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Carsten Bormann
>> Sent: jeudi 7 février 2019 12:42
>> To: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
>> Cc: 6lo@ietf.org
>> Subject: Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB
>> entries?
>> 
>> On Feb 7, 2019, at 12:36, Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> wrote:
>>> 
>>> Since datagram_tag is expected to be incremented (by one) as RFC4944
>> specifies, holding the last datagram_tag per peer may be enough, although this
>> kind of thing could be "implementation-specific":
>> 
>> Right.  We don’t want to blackhole datagrams after a reboot, and we want to
>> allow the sending implementation to forget their neighbor state (which might
>> include that counter, if it is not global) after a while.  So I think some form of
>> timeout may be needed.
>> 
>> Grüße, Carsten
>> 
>> _______________________________________________
>> 6lo mailing list
>> 6lo@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo