Hi,
On Mon, Dec 20, 2010 at 2:05 PM, Stewart Bryant <stbryant(_at_)cisco(_dot_)com>
wrote:
On 20/12/2010 18:43, Donald Eastlake wrote:
Hi,
On Mon, Dec 20, 2010 at 11:42 AM, Sam
Hartman<hartmans-ietf(_at_)mit(_dot_)edu>
wrote:
"Radia" == Radia Perlman<radiaperlman(_at_)gmail(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf