Hi, On Mon, Dec 20, 2010 at 2:05 PM, Stewart Bryant <stbry...@cisco.com> wrote: > On 20/12/2010 18:43, Donald Eastlake wrote: >> >> Hi, >> >> On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartman<hartmans-i...@mit.edu> >> wrote: >>>>>>>> "Radia" == Radia Perlman<radiaperl...@gmail.com> writes: >>> >>> Radia> No objections. Radia >>> >>> Can I get someone to confirm that the text in the proposed sentences is >>> substantially true? >>> I think so but I'm not an IS-IS expert. >> >> LSPs have sequences number, etc., and are idempotent. I think only >> Hellos have the potential replay Denial of Service problem. So I would >> suggest changing to: >> >> "Even when the IS-IS >> authentication is used, replays of Hello packets can create >> denial-of-service conditaions; see RFC 6039 for details. These issues >> are similar in scope to those discussed in section 6.2 of >> draft-ietf-trill-rbridge-protocol, and the same mitigations may apply." >> >> Thanks, >> Donald > > ... as I recall from discussions with the ISIS WG the changes that were made > to ISIS for TRILL make it more vulnerable to a hello attack than vanilla > ISIS. This I understand is because there is more work to be done in > processing a TRILL hello. Is that correct?
I think we are talking about Denial of Service due to replay of old Hellos screwing up the state. This is unrelated to the work required to process a Hello. It is true that some processing is required for IS-IS LAN Hellos. One reason for having a protocol like BFD is that you can send BFD messages more frequently because they take less processing than Hellos. But I don't see why there would be that much difference between the work involved in processing a TRILL LAN Hello and a Layer 3 IS-IS LAN Hello. > - Stewart Thanks, Donald _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
