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 <[email protected]> On Behalf Of Carsten Bormann > Sent: jeudi 7 février 2019 12:42 > To: Yasuyuki Tanaka <[email protected]> > Cc: [email protected] > Subject: Re: [6lo] draft-ietf-6lo-minimal-fragment-00: When to remove VRB > entries? > > On Feb 7, 2019, at 12:36, Yasuyuki Tanaka <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/6lo _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
