Hi Les, Please see inline with [Jie]:
From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Monday, August 01, 2016 3:09 PM To: Dongjie (Jimmy); [email protected] Cc: Zhangxudong (zhangxudong, VRP); [email protected] Subject: RE: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement Jie - Fully agree that IS-IS and OSPF differ in this regard. https://www.ietf.org/id/draft-ietf-isis-remaining-lifetime-01.txt addresses problems where corruption of the remaining lifetime occurs either during transmission/reception or due to some DOS attack. This isn't a concern w OSPF (hope you agree). [Jie]: Yes, for OSPF the corruption during packet transmission can be detected. What remains is the possibility that an implementation has some bug and unintentionally modifies the age to something other than what it should be due to the actual elapsed time since LSA generation. I suppose a mechanism equivalent to what the IS-IS draft defined i.e. setting the age to "new" (0 in OSPF case) when first receiving a non-self-generated LSA could be useful to prevent negative impacts of such an implementation bug. Is this what you intend? [Jie]: More specifically, the problem could be caused by either "setting the LS age field incorrectly due to implementation bug" or "system timer runs so fast that the LS age reaches MaxAge much earlier than other routers". Another less likely case is that the LS age field is corrupted before the LSA is assembled into OSPF packet. [Jie]: Regarding the solutions space, IMO we need to consider both cases: "LS age reaches MaxAge" and "LS age close to MaxAge". For IS-IS, RFC 6232 and RFC 6233 provide solutions for the detection and identification of corrupted IS-IS purge, while OSPF does not have similar mechanisms. As written, the draft makes claims that are at least misleading - and I believe actually incorrect. In Section 6 you say: "The LS age field may be altered as a result of packet corruption, such modification cannot be detected by LSA checksum nor OSPF packet cryptographic authentication." This isn't correct. [Jie] Thanks for pointing out this. This sentence need to be revised to mention "LSA corruption" rather than "packet corruption". What would be helpful - at least to me - is to move from a generic problem statement to the specific problem you want to solve and the proposed solution. This also requires you to more clearly state the cases where there is an actual vulnerability. It would be a lot easier to support the draft if this were done. [Jie] Thanks for your suggestion. Yes we can update this draft with more specific problem statements as I mentioned above. [Jie] As for the proposed solutions, the current draft specifies the requirements on the potential solutions, from which we envision that different solutions maybe needed for "Impact Mitigation" and "Problem Localization". Impact mitigation can be the easier one, for which we can start to discuss the potential solution. While the solution for "problem localization" may need more considerations. Best regards, Jie Les From: Dongjie (Jimmy) [mailto:[email protected]] Sent: Sunday, July 31, 2016 11:48 PM To: Les Ginsberg (ginsberg); [email protected]<mailto:[email protected]> Cc: Zhangxudong (zhangxudong, VRP); [email protected]<mailto:[email protected]> Subject: RE: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement Hi Les, Thanks for your comments. OSPF packet level checksum and authentication can only protect the assembled LSU packet one hop on the wire, while cannot detect any change to LSA made by the routers. This is because the OSPF packets are re-assembled on each hop, which is slightly different from IS-IS. So the problem for OSPF is mainly due to the problems inside the router, for example protocol implementations, system timers, or some hardware problem. Actually this problem has been seen in several production networks. We can improve the description in the draft to make this clear. Best regards, Jie From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Monday, August 01, 2016 1:30 PM To: Dongjie (Jimmy); [email protected]<mailto:[email protected]> Cc: Zhangxudong (zhangxudong, VRP); [email protected]<mailto:[email protected]> Subject: RE: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement Jie - The draft says (Section 2): "Since cryptographic authentication is executed at the OSPF packet level, it can only protect the assembled LSU packet for one hop and does not provide any additional protection for the corruption of LS age field." But as authentication is calculated at the OSPF packet level, any change to the LS age field for an individual LSA contained within the OSPF packet (e.g. by some packet corruption in transmission) would cause authentication to fail when the packet is received. So the statement you make is not correct. I therefore am struggling to understand what problem you believe is not addressed by existing authentication techniques. Les From: OSPF [mailto:[email protected]] On Behalf Of Dongjie (Jimmy) Sent: Sunday, July 31, 2016 8:15 PM To: [email protected]<mailto:[email protected]> Cc: Zhangxudong (zhangxudong, VRP); [email protected]<mailto:[email protected]> Subject: [OSPF] Solicit feedbacks on draft-dong-ospf-maxage-flush-problem-statement Hi all, draft-dong-ospf-maxage-flush-problem-statement describes the problems caused by the corruption of the LS Age field, and summarizes the requirements on potential solutions. This draft received good comments during the presentation on the IETF meeting in B.A. The authors would like to solicit further feedbacks from the mailing list, on both the problem statement and the solution requirements. Based on the feedbacks, we will update the problem statement draft, and work together to build suitable solutions. The URL of the draft is: https://tools.ietf.org/html/draft-dong-ospf-maxage-flush-problem-statement-00 Comments & feedbacks are welcome. Best regards, Jie
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
