Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)
Hi Roman, >>> -- What are the relevant pointers to IS-IS security considerations? >> >> >> AFAIK, there is no overall document for IS-IS’ security architecture. The >> only >> pointers I can suggest are to RFC 5304 and 5310. I will happily add >> references >> to these if folks feel that’s helpful. > > > Thanks for this explanation. I clear on this point. Adding those references > to the SecCons would be helpful. Added. Tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)
Hi Tony! Thanks for the explanation. See below. > -Original Message- > From: Tony Li On Behalf Of Tony Li > Sent: Tuesday, January 9, 2024 5:31 PM > To: Roman Danyliw > Cc: The IESG ; draft-ietf-lsr-isis-area-pr...@ietf.org; > lsr-chairs > ; lsr ; Christian Hopps > Subject: Re: Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: > (with > DISCUSS and COMMENT) > > Warning: External Sender - do not click links or open attachments unless you > recognize the sender and know the content is safe. > > > Hi Roman, Alexy, > > Thank you for your comments. > > > -- > > DISCUSS: > > -- > > > > ** Section 4.3. Do all the candidates need the Area Proxy System > > Identifier TLVs need the same system identifier? > > > I’m not sure I understand the question. Let me prattle on a bit and please let > me know if I do not address the question. > > Vanilla IS-IS requires that each node in the routing domain have a unique > system identifier. > This is unchanged. > > Area Proxy extends this by requiring an additional system identifier for the > Area Proxy. This is the Area Proxy System Identifier. This is normally > advertised > by the Area Leader so that all Interior Nodes know the value and it’s used by > Interior Edge Nodes. It’s a good idea to have multiple candidates for Area > Leader for resiliency, and having them all configured with the same Area Proxy > System Identifier is strongly preferred out of consistency. However, it is NOT > required. It is not an error for there to be multiple different candidate Area > Proxy System Identifiers. In fact, this situation might happen if someone has > decided to change the Area Proxy System Identifier and is in the midst of > reconfiguring part of the routing domain. > > This does not cause confusion because Area Leader election is going to elect a > single leader and all systems will use the Area Proxy System Identifier that > the > leader is advertising. > > Yes, if there is a change in leader, there may be a transient change in the > Area > Proxy System Identifier. This would cause a set of adjacency flaps, just as > changing any regular system identifier would. > > > > -- Section 4.2 says “For consistency, all Area Leader candidates > > SHOULD be configured with the same Proxy System ID, Proxy Hostname, > > and any other information that may be inserted into the Proxy LSP.” > > > The rationale is similar to the above. Is there a separate question? > > > > -- Section 4.3.1 says: “All candidates advertising the Area Proxy > > System Identifier TLV MUST be advertising the same system identifier.” > > > I will relax this to a SHOULD. > > > > The first statement suggests that consistency might not always be > > required, but the second statement is clear that it always must be the same > identifier. I very much appreciate the explanation. The bottom line issue was the inconsistency between the two statements highlighted by the "--" bullets. The proposed change to SHOULD in Section 4.3.1 addressed my feedback. > > ** Section 8. The following statement doesn’t appear to be accurate. > > > > 8. Security Considerations > > > > This document introduces no new security issues. Security of routing > > within a domain is already addressed as part of the routing protocols > > themselves. This document proposes no changes to those security > > architectures. > > > > -- Aren’t a few the filtering activities described in Section 5.2 > > security-related? > > > No. These are key for ensuring the benefits of Area Proxy, most especially > scalability, but if they are violated, it is not necessarily catastrophic. > > Some examples: > > - If the L1 LSP of an Inside Router is leaked outside of the area, then it > would be > a protocol error, but other routers should recognize that they are not part of > that area and ignore the LSP. > > - If the L2 LSP of an Inside Router is leaked outside of the area, then it > would be > accepted by other routers, but it would have no two-way adjacencies with > anything else in L2 and effectively be disconnected from the topology. > > - Incorrect PSNP or CSNPs would prompt the receiving system to send PSNPs > for Inside LSPs, but this would not per se cause problems. > > > > -- What are the relevant pointers to IS-IS security considerations? > > > AFAIK, there is no overall document for IS-IS’ security architecture. The only > p
Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)
Hi Roman, Alexy, Thank you for your comments. > -- > DISCUSS: > -- > > ** Section 4.3. Do all the candidates need the Area Proxy System Identifier > TLVs need the same system identifier? I’m not sure I understand the question. Let me prattle on a bit and please let me know if I do not address the question. Vanilla IS-IS requires that each node in the routing domain have a unique system identifier. This is unchanged. Area Proxy extends this by requiring an additional system identifier for the Area Proxy. This is the Area Proxy System Identifier. This is normally advertised by the Area Leader so that all Interior Nodes know the value and it’s used by Interior Edge Nodes. It’s a good idea to have multiple candidates for Area Leader for resiliency, and having them all configured with the same Area Proxy System Identifier is strongly preferred out of consistency. However, it is NOT required. It is not an error for there to be multiple different candidate Area Proxy System Identifiers. In fact, this situation might happen if someone has decided to change the Area Proxy System Identifier and is in the midst of reconfiguring part of the routing domain. This does not cause confusion because Area Leader election is going to elect a single leader and all systems will use the Area Proxy System Identifier that the leader is advertising. Yes, if there is a change in leader, there may be a transient change in the Area Proxy System Identifier. This would cause a set of adjacency flaps, just as changing any regular system identifier would. > -- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be > configured with the same Proxy System ID, Proxy Hostname, and any other > information that may be inserted into the Proxy LSP.” The rationale is similar to the above. Is there a separate question? > -- Section 4.3.1 says: “All candidates advertising the Area Proxy System > Identifier TLV MUST be advertising the same system identifier.” I will relax this to a SHOULD. > The first statement suggests that consistency might not always be required, > but > the second statement is clear that it always must be the same identifier. > > ** Section 8. The following statement doesn’t appear to be accurate. > > 8. Security Considerations > > This document introduces no new security issues. Security of routing > within a domain is already addressed as part of the routing protocols > themselves. This document proposes no changes to those security > architectures. > > -- Aren’t a few the filtering activities described in Section 5.2 > security-related? No. These are key for ensuring the benefits of Area Proxy, most especially scalability, but if they are violated, it is not necessarily catastrophic. Some examples: - If the L1 LSP of an Inside Router is leaked outside of the area, then it would be a protocol error, but other routers should recognize that they are not part of that area and ignore the LSP. - If the L2 LSP of an Inside Router is leaked outside of the area, then it would be accepted by other routers, but it would have no two-way adjacencies with anything else in L2 and effectively be disconnected from the topology. - Incorrect PSNP or CSNPs would prompt the receiving system to send PSNPs for Inside LSPs, but this would not per se cause problems. > -- What are the relevant pointers to IS-IS security considerations? AFAIK, there is no overall document for IS-IS’ security architecture. The only pointers I can suggest are to RFC 5304 and 5310. I will happily add references to these if folks feel that’s helpful. > -- > COMMENT: > -- > > Thank you to Alexey Melnikov for the SECDIR review. > > ** Section 4.3.1 > However, before withdrawing the Area Proxy > System Identifier, an implementation SHOULD protect against > unnecessary churn from transients by delaying the withdrawal. The > amount of delay is implementation-dependent. > > Are there any guidelines on how the delay period should be computed? I don’t have any specific suggestions. My implementation practice is to apply binary exponential backoff, with some ridiculous upper bound, but the specifics are well outside of the boundaries of a protocol spec. > ** Section 4.4.4. > An entry for a neighbor in both the IS Neighbors TLV and the Extended > IS Neighbors would be functionally redundant, so the Area Leader > SHOULD NOT do this. > > Under what circumstances would this advice be ignored (i.e., why not a MUST)? This is not a MUST because it’s a redundancy, not an error. > ** Section 4.4.5 and 4.4.6 describe various behavior where fields “SHOULD” be > copied. What governs the choice of not
[Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-lsr-isis-area-proxy-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/ -- DISCUSS: -- ** Section 4.3. Do all the candidates need the Area Proxy System Identifier TLVs need the same system identifier? -- Section 4.2 says “For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System ID, Proxy Hostname, and any other information that may be inserted into the Proxy LSP.” -- Section 4.3.1 says: “All candidates advertising the Area Proxy System Identifier TLV MUST be advertising the same system identifier.” The first statement suggests that consistency might not always be required, but the second statement is clear that it always must be the same identifier. ** Section 8. The following statement doesn’t appear to be accurate. 8. Security Considerations This document introduces no new security issues. Security of routing within a domain is already addressed as part of the routing protocols themselves. This document proposes no changes to those security architectures. -- Aren’t a few the filtering activities described in Section 5.2 security-related? -- What are the relevant pointers to IS-IS security considerations? -- COMMENT: -- Thank you to Alexey Melnikov for the SECDIR review. ** Section 4.3.1 However, before withdrawing the Area Proxy System Identifier, an implementation SHOULD protect against unnecessary churn from transients by delaying the withdrawal. The amount of delay is implementation-dependent. Are there any guidelines on how the delay period should be computed? ** Section 4.4.4. An entry for a neighbor in both the IS Neighbors TLV and the Extended IS Neighbors would be functionally redundant, so the Area Leader SHOULD NOT do this. Under what circumstances would this advice be ignored (i.e., why not a MUST)? ** Section 4.4.5 and 4.4.6 describe various behavior where fields “SHOULD” be copied. What governs the choice of not copying these fields? Would operators be impacted in troubleshooting or even operations if different implementations applied this advice differently? Would it be up to local configuration? Later sections in 4.4.* also have “SHOULD” behavior as well where the reason for not following the behavior is not clear. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
