Sigh Yours Irrespectively,
John > -----Original Message----- > From: Acee Lindem [mailto:acee.lin...@gmail.com] > Sent: Monday, January 05, 2015 10:20 AM > To: John E Drake > Cc: Acee Lindem (acee); adr...@olddog.co.uk; Stephen Farrell; The IESG; > OSPF List; ospf-cha...@tools.ietf.org; draft-ietf-ospf-te-metric- > extensions....@tools.ietf.org > Subject: Re: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-te- > metric-extensions-09: (with COMMENT) > > Hi John, > I realized now I have one more comment that is better late than never. Can > you add a reference to RFC 5329 in the abstract, section 3, section 10, and > section 11? There is no reason why these metric extensions shouldn't apply > equally to the OSPFv3 TE. > Thanks, > Acee > On Jan 5, 2015, at 10:00 AM, John E Drake <jdr...@juniper.net> 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-boun...@ietf.org] On Behalf Of Acee Lindem > >> (acee) > >> Sent: Monday, January 05, 2015 9:51 AM > >> To: adr...@olddog.co.uk; 'Stephen Farrell'; 'The IESG' > >> Cc: ospf@ietf.org; ospf-cha...@tools.ietf.org; > >> draft-ietf-ospf-te-metric- extensions....@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" <adr...@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 > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
