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

From: "Stephen Farrell" <[email-masked]>
Date: Sat, 03 Jan 2015 18:07:18 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-ospf-te-metric-extensions-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-ospf-te-metric-extensions/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

These are mainly nits or questions, other than the
first.  That would have been a discuss if I knew of a
specific threat, but since this is just a general
concern, it's not a discuss. I'd appreciate a bit of
a chat about it though.

- 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?)

- intro: "extremely large amounts of money" aren't
usually explicit motivations for protocol features and I
hope that that continues to be the case. I'd encourage
you to remove that phrase. Similarly, "faster" is a fine
requirement but "fast than the competition" is not, so a
bit more wordsmithing might be good. (Those are, I
think, defensible points as we ought not over-specialise
our requirements, but to be honest I'd also be happier
if protocol development was not explicitly motivated
soley by increasing already-enormous amounts of money.)

- intro: saying the "measurement of delay SHOULD NOT
vary significantly based upon the offered traffic load"
is odd. Clearly the delay experienced can vary based on
the load, so I'm not sure what you're saying. And nor is
it clear why this is a SHOULD NOT, as opposed to a MUST
NOT. Maybe you need to explain that some more?

- section 3: Doesn't the A bit definition assume that
both senders and receivers know the thresholds (or
enough about those). That seems a bit odd to me, but I
expect you've thought it through.  Same thing with the
averaging period I guess (though section 7 does specify
a 30s default as a SHOULD). Or am I missing that one
could calculate those from the various TLVs that are
defined?  (I think I'm also not understanding bullet
point 4 in section 5 which may be related.)

- section 3: I don't get what "cannot be used for
fail-over purposes" means. I think you mean "ought not"
since a receiver can do what they want in any case.

- 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?

- In one response to the secdir review, [1] path
shortening attacks were mentioned - I'm not clear myself
if that's a deal here, but is text on that needed?

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05354.html

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Jan 2015 09:39:45 -0000

Hi Stephen,

I'd like the authors and shepherd to pitch in, but...

> that considered by the WG? (Can you send a relevant link

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.

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.

[snip]

> last decade+ that would be worth noting here?

That is a good point. There is plenty of newer security work.

Adrian

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 04 Jan 2015 13:55:58 +0000

Hiya,

Thanks - fine answer to my not-quite-discuss.

Cheers,
S.

On 04/01/15 09:39, Adrian Farrel wrote:
>> - 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.
> 
> 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.
> 
> [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?
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 5 Jan 2015 14:51:12 +0000

Hi Stephen, Adrian,

On 1/4/15, 4:39 AM, "Adrian Farrel" <[email-masked]> wrote:

>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.
>

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:
>- 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).

>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

---

From: John E Drake <[email-masked]>
Date: Mon, 5 Jan 2015 15:00:40 +0000

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-masked]] On Behalf Of Acee Lindem
> (acee)
> Sent: Monday, January 05, 2015 9:51 AM
> To: [email-masked]; 'Stephen Farrell'; 'The IESG'
> Cc: [email-masked]; [email-masked]; draft-ietf-ospf-te-metric-
> [email-masked]
> Subject: Re: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-te-
> metric-extensions-09: (with COMMENT)
> 
> Hi Stephen, Adrian,
> 
> >> 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?)
> >
> >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.
> >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.
> >
> >advertised within a network. There are four elements:
> >- If a node attempts to join a network to access the information it
> >will be unknown and will not be able to peer.
> >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 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]
> >
> >> 11 lines long. Has nothing affected OSPF security in the last decade+
> >> that would be worth noting here?
> >
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 05 Jan 2015 15:05:04 +0000

Thanks all and sorry for being nitty:-)

S

On 05/01/15 15:00, John E Drake wrote:
>> -----Original Message----- From: OSPF
>> [mailto:[email-masked]] On Behalf Of Acee Lindem (acee) 
>> Sent: Monday, January 05, 2015 9:51 AM To: [email-masked];
>> 'Stephen Farrell'; 'The IESG' Cc: [email-masked];
>> [email-masked]; draft-ietf-ospf-te-metric- 
>> [email-masked] Subject: Re: [OSPF] Stephen Farrell's
>> No Objection on draft-ietf-ospf-te- metric-extensions-09: (with
>> COMMENT)
>> 
>> Hi Stephen, Adrian,
>> 
>>>> - 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.
>>> 
>>> 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.
>>> 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.
>>> 
>>> 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.
>> 
>> 
>> 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?
>>> 
>> 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-masked] https://www.ietf.org/mailman/listinfo/ospf
>

---

From: John E Drake <[email-masked]>
Date: Mon, 5 Jan 2015 15:23:45 +0000

Sigh

Yours Irrespectively,

John

> From: Acee Lindem [mailto:[email-masked]]
> Sent: Monday, January 05, 2015 10:20 AM
> To: John E Drake
> Cc: Acee Lindem (acee); [email-masked]; Stephen Farrell; The IESG;
> OSPF List; [email-masked]; draft-ietf-ospf-te-metric-
> 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 <[email-masked]> wrote:
> 
> > Acee,
> >
> >> Cc: [email-masked]; [email-masked];
> >> draft-ietf-ospf-te-metric- [email-masked]
> >>> 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.
> >>>
> >>> stressing the
> >>> 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
> >>> - 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.
> >>>
> >> 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]
> >>>
> >>>> 11 lines long. Has nothing affected OSPF security in the last
> >> and