Brian and Stephen, While I agree that the Security section of this document could have included more references to state of the art OSPF security, I believe this has been fixed in -10. So I find myself wondering ...
> I agree with Stephen that the specified use cases seem to warrant a > stronger recommendation to provide authentication and confidentiality. > The tools are available, so why are they not being recommended in this > instance? What is it about these specific TLVs in an TLV of an existing opaque LSA that cause you to see a higher concern for authentication and confidentiality than the previously existing ones? Do you, for example, think that an attacker might cause more damage by inserting an LSA containing a Unidirectional Link Delay TLV than it would by inserting an LSA containing a Local interface IP address TLV? As far as authentication is concerned, an attacker that is able to inject LSAs into the OSPF network is able to do considerable and "interesting" damage. Do you consider that the information in a Unidirectional Residual Bandwidth TLV is more sensitive to sniffing than, say, the Shared Risk Link Group TLV? The value of confidentiality of on-wire IGP advertisements will depend on the network and the planned attack. What can you work out from the delay metrics? Possibly short link length makes a link more interesting to attack because it will be carrying more valuable data? But it is the end-to-end delay that is used to determine where to place traffic, not the delay on any one specific link. What am I missing about your concerns? Thanks, Adrian _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
