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

["Acee Lindem (acee)" <[e-mail]>]

Hi Stephen, Adrian,

On 1/4/15, 4:39 AM, "Adrian Farrel" <[e-mail]> 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
>