Hi Stephen, Adrian, On 1/4/15, 4:39 AM, "Adrian Farrel" <[email protected]> wrote:
>Hi Stephen, > >I'd like the authors and shepherd to pitch in, but... > >> - I'd have thought that these TLVs would be sent more >> often than others, and that (if enormous amounts of >> money are in play) then use of OSPF authentication might >> be more likely needed (or some equivalent security >> mechanisms). I'd even speculate that if enormous amounts >> of money are in play, then confidentiality may become a >> requirement (since if I can observe say A bit settings >> then that might give me insight into traffic levels - >> sort of a lights burning at night in central bank >> implies interest-rate change attack). Can you say why >> none of that needs to be mentioned at all? Was any of >> that considered by the WG? (Can you send a relevant link >> to the archive?) > >I think you are raising two points: >1. Are the TLVs sent more often than others and what are the implications? >2. What can be learned from sniffing these TLVs? > >To the first point, I don't think they are sent more often than other TE >TLVs. Indeed metrics for loss and delay may be more stable than others, >and Section 5 addresses measurement intervals and projects that on to >announcement thresholds. > >So the risk is that changes in bandwidth availability will cause rapid or >frequent announcement of those metrics. However, just like the original >bandwidth metrics, implementations apply thresholds so that small changes >don't trigger re-announcement in order to avoid stressing the network. >Section 6 discusses this. > >Thus, I think we can discard 1. Agreed. This is covered in sections 5 and 6. > >The second point is important: you can find out a lot about a network by >sniffing the IGP, and if your plan is to understand the state of your >competitor's network or to find the week spots to attack, then this is a >powerful tool. But in this matter I would argue that these no TLVs are no >more sensitive than other, pre-existing TLVs, although (of course) the >more TLVs, the more information is available to be sniffed. > >So, the question is how do we protect IGP information as it is advertised >within a network. There are four elements: >- IGP information is retained within an administrative domain. >- If a router is compromised it has access to all of the information and >there is nothing we can do. >- If a node attempts to join a network to access the information it will >be unknown and will not be able to peer. >- If a link is sniffed (which is a somewhat more sophisticated attack) >protection relies on encryption of the messages most probably at layer 2, >but potentially at IP (which is an option for OSPF) or within the OSPF >messages themselves. > >I think all of this is just "IGP security as normal", was discussed by >KARP, and is everyday business for network operators. I agree. I can¹t see that delay/loss would be more sensitive than reachability information. I guess the premise is that one might want to target better for links for DDoS attacks? I do not recall this coming up in the discussions on either the OSPF or ISIS lists (there is an ISIS draft advertising the same TLVs). > >[snip] > >> - The security considerations of RFC 3630, from 2003, is >> 11 lines long. Has nothing affected OSPF security in the >> last decade+ that would be worth noting here? > >That is a good point. There is plenty of newer security work. This should include RFC 6863 for analysis, RFC 5709 for protection, and draft-ietf-ospf-security-extension-manual-keying-11 for protection. John? Thanks, Acee > >Adrian > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
