On 8/17/15, 9:41 AM, "Acee Lindem (acee)" <[email protected]> wrote:
Acee: Hi! Thanks for looking into my comments! Just one more thing below. Alvaro. . . . >>2. Section 2.1. (OSPFv2 Extended Prefix TLV) >> >>a. For the Route Type, are those the only allowed values? What happens >>if something else is used? > >Yes - these are the only route types allowed. If an invalid type is >specified, the attributes will not be correlated with a route. I¹m glad you brought this up ‹ the correlation. I should¹ve commented on this before.. I don¹t think the draft talks about how to correlate the additional information back to the ³normal² LSAs. Given that it is important for the route type and the prefix to match (anything else?), it would be good if it was called out somewhere. I¹m assuming that the fact that the correlation is not made will just result in lost information ‹ but some application may really want this information, so loosing it could be importante for them. Explaining the potential impact would be very good. Same comment for the other TLV.. . . . >>4. Section 6. (Security Considerations) >> >>a. I think you should also point the readers at the considerations in >>rfc5250. >> >>b. ³Šimplementations must assure that malformed TLV and Sub-TLV >>permutations do not result in errors that cause hard OSPF failures.² >>What does that mean? That the software should be resilient? Or are you >>pointing at just ignoring the information if there is a malformed >>TLV/sub-TLV (that is somehow salvageable)? It would be vey nice is this >>draft set the example by specifying what to do in some cases (maybe not >>malformed, but incorrect/unknown as mentioned above). > > >This stems from prior attacks on routing protocols involved carefully >crafted malformed TLVs which could result in software crashes. Ahh..ok. Still, explaining what to do with malformed information would be good. This obviously goes back to the loss of information. _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
