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:[email protected]] On Behalf Of Acee Lindem > (acee) > Sent: Monday, January 05, 2015 9:51 AM > To: [email protected]; 'Stephen Farrell'; 'The IESG' > Cc: [email protected]; [email protected]; draft-ietf-ospf-te-metric- > [email protected] > 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" <[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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
