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

Thanks all and sorry for being nitty:-)

S

On 05/01/15 15:00, John E Drake wrote:
> Acee,
> 
> I will take care of Stephen's nits and add the references you mention
> to the Security Considerations.
> 
> Yours Irrespectively,
> 
> John
> 
>> -----Original Message----- From: OSPF
>> [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee) 
>> Sent: Monday, January 05, 2015 9:51 AM To: adrian@olddog.co.uk;
>> 'Stephen Farrell'; 'The IESG' Cc: ospf@ietf.org;
>> ospf-chairs@tools.ietf.org; draft-ietf-ospf-te-metric- 
>> extensions.all@tools.ietf.org Subject: Re: [OSPF] Stephen Farrell's
>> No Objection on draft-ietf-ospf-te- metric-extensions-09: (with
>> COMMENT)
>> 
>> Hi Stephen, Adrian,
>> 
>> On 1/4/15, 4:39 AM, "Adrian Farrel" <adrian@olddog.co.uk> 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 
>> OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
>