Re: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-te-metric-extensions-09: (with COMMENT)

["Adrian Farrel" <[e-mail]>]

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.

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.

[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.

Adrian