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

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