Re: [secdir] Secdir review of draft-ietf-isis-trill
No objections. Radia On Sun, Dec 19, 2010 at 10:16 AM, Donald Eastlake d3e...@gmail.com wrote: My apologies for responding slowly, I was traveling. If it is tolerable to people, I do not mind adding the two sentences requested by Sam to the isis-trill draft. Thanks, Donald PS: It appears to me that the same considerations apply to draft-ietf-isis-ieee-aq. On Fri, Dec 17, 2010 at 10:45 PM, Sam Hartman hartmans-i...@mit.edu wrote: Erik == Erik Nordmark nordm...@acm.org writes: Erik Adding just this sentence to draft-ietf-isis-trill (the code Erik point document) seems odd. Your comment is really a comment on Erik the security of IS-IS, and not specific to TRILL and unrelated Erik to the code points. I don't care much where the text goes. I'm happy if you provide an rfc editor note for draft-ietf-trill-rbridge-protocol if you like that approach better. However, as I read draft-ietf-isis-trill, it defines the interface between TRILL and IS-IS. In my mind, that's where the security consideration appears. You're re-using a component that isn't up to our current standards--we know that; we're working on it in KARP. However in doing that, you need to document the security considerations for your protocol. Since you have a document that specifically is the interface between your protocol and the component you are re-using,that seems like the best place to do the documentation work. however, in decreasing order of priority, I want to call out my concern that we need to be far more careful about what we expect in terms of security from future work we charter and that we should document the specific interactions between IS-IS and TRILL. While I have expressed an opinion above on where I think that documentation should go, feel free to put it where you think is most correct. ___ secdir mailing list sec...@ietf.org https://www.ietf.org/mailman/listinfo/secdir ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
Donald == Donald Eastlake d3e...@gmail.com writes: Donald Hi, Donald 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. Donald LSPs have sequences number, etc., and are idempotent. I Donald think only Hellos have the potential replay Denial of Donald Service problem. So I would suggest changing to: Donald Even when the IS-IS authentication is used, replays of Donald Hello packets can create denial-of-service conditaions; see Donald RFC 6039 for details. These issues are similar in scope to Donald those discussed in section 6.2 of Donald draft-ietf-trill-rbridge-protocol, and the same mitigations Donald may apply. Based on my understanding your correction is accurate; thanks. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
On 20/12/2010 18:43, Donald Eastlake wrote: Hi, On Mon, Dec 20, 2010 at 11:42 AM, Sam Hartmanhartmans-i...@mit.edu wrote: Radia == Radia Perlmanradiaperl...@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? - Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [secdir] Secdir review of draft-ietf-isis-trill
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 Hartmanhartmans-i...@mit.edu wrote: Radia == Radia Perlmanradiaperl...@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
Re: [secdir] Secdir review of draft-ietf-isis-trill
My apologies for responding slowly, I was traveling. If it is tolerable to people, I do not mind adding the two sentences requested by Sam to the isis-trill draft. Thanks, Donald PS: It appears to me that the same considerations apply to draft-ietf-isis-ieee-aq. On Fri, Dec 17, 2010 at 10:45 PM, Sam Hartman hartmans-i...@mit.edu wrote: Erik == Erik Nordmark nordm...@acm.org writes: Erik Adding just this sentence to draft-ietf-isis-trill (the code Erik point document) seems odd. Your comment is really a comment on Erik the security of IS-IS, and not specific to TRILL and unrelated Erik to the code points. I don't care much where the text goes. I'm happy if you provide an rfc editor note for draft-ietf-trill-rbridge-protocol if you like that approach better. However, as I read draft-ietf-isis-trill, it defines the interface between TRILL and IS-IS. In my mind, that's where the security consideration appears. You're re-using a component that isn't up to our current standards--we know that; we're working on it in KARP. However in doing that, you need to document the security considerations for your protocol. Since you have a document that specifically is the interface between your protocol and the component you are re-using,that seems like the best place to do the documentation work. however, in decreasing order of priority, I want to call out my concern that we need to be far more careful about what we expect in terms of security from future work we charter and that we should document the specific interactions between IS-IS and TRILL. While I have expressed an opinion above on where I think that documentation should go, feel free to put it where you think is most correct. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
