Subject: [OSPF] Brian Haberman's No Objection on draft-ietf-ospf-te-metric-extensions-10: (with COMMENT)

From: "Brian Haberman" <[email-masked]>
Date: Tue, 06 Jan 2015 06:55:09 -0800

Brian Haberman has entered the following ballot position for
draft-ietf-ospf-te-metric-extensions-10: 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:
----------------------------------------------------------------------

I agree with Stephen that the specified use cases seem to warrant a
stronger recommendation to provide authentication and confidentiality. 
The tools are available, so why are they not being recommended in this
instance?

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Jan 2015 15:48:55 -0000

Brian and Stephen,

While I agree that the Security section of this document could have included more references to state of the art OSPF security, I believe this has been fixed in -10. So I find myself wondering ...

> The tools are available, so why are they not being recommended in this

What is it about these specific TLVs in an TLV of an existing opaque LSA that cause you to see a higher concern for authentication and confidentiality than the previously existing ones?

Do you, for example, think that an attacker might cause more damage by inserting an LSA containing a Unidirectional Link Delay TLV than it would by inserting an LSA containing a Local interface IP address TLV? As far as authentication is concerned, an attacker that is able to inject LSAs into the OSPF network is able to do considerable and "interesting" damage.

Do you consider that the information in a Unidirectional Residual Bandwidth TLV is more sensitive to sniffing than, say, the Shared Risk Link Group TLV? The value of confidentiality of on-wire IGP advertisements will depend on the network and the planned attack. What can you work out from the delay metrics? Possibly short link length makes a link more interesting to attack because it will be carrying more valuable data? But it is the end-to-end delay that is used to determine where to place traffic, not the delay on any one specific link.

What am I missing about your concerns?

Thanks,
Adrian

---

From: joel jaeggli <[email-masked]>
Date: Tue, 06 Jan 2015 09:13:15 -0800

> Do you consider that the information in a Unidirectional Residual Bandwidth TLV is more sensitive to sniffing than, say, the Shared Risk Link Group TLV? The value of confidentiality of on-wire IGP…
The implications for having a miscreant participate in your igp are
pretty dire, but I've at a loss to understand how they become more dire
with new tlvs. ospf md5 auth or ospfv3 esp encapsulation with static
keying is basically something an operator uses to prevent adjacency from
accidentally configured devices.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 06 Jan 2015 12:17:37 -0500

Hi Adrian,

On 1/6/15 10:48 AM, Adrian Farrel wrote:
> Brian and Stephen,
> 
> While I agree that the Security section of this document could have
> included more references to state of the art OSPF security, I believe
> this has been fixed in -10. So I find myself wondering ...

http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-10#section-11
does say that RFC 5709  and
draft-ietf-ospf-security-extension-manual-keying provide additional
protection for OSPFv2, but it doesn't suggest/recommend that they be used.

> 
>> I agree with Stephen that the specified use cases seem to warrant
>> a stronger recommendation to provide authentication and
>> confidentiality. The tools are available, so why are they not being
>> recommended in this instance?
> 
> What is it about these specific TLVs in an TLV of an existing opaque
> LSA that cause you to see a higher concern for authentication and
> confidentiality than the previously existing ones?

As Stephen put it, if there is a lot of money involved it makes sense to
recommend a stronger level of protection.  But, more generally, I think
the world has changed enough that we need to be making stronger
recommendations to protect all information.

> 
> Do you, for example, think that an attacker might cause more damage
> by inserting an LSA containing a Unidirectional Link Delay TLV than
> it would by inserting an LSA containing a Local interface IP address
> TLV? As far as authentication is concerned, an attacker that is able
> to inject LSAs into the OSPF network is able to do considerable and
> "interesting" damage.
> 
> Do you consider that the information in a Unidirectional Residual
> Bandwidth TLV is more sensitive to sniffing than, say, the Shared
> Risk Link Group TLV? The value of confidentiality of on-wire IGP
> advertisements will depend on the network and the planned attack.
> What can you work out from the delay metrics? Possibly short link
> length makes a link more interesting to attack because it will be
> carrying more valuable data? But it is the end-to-end delay that is
> used to determine where to place traffic, not the delay on any one
> specific link.
> 

If I can make routers believe that a particular link has a high delay, I
can make that router send the traffic over a different link that I know
has a longer delay.  Even a few milliseconds difference in data transfer
can have a huge impact on micro-trading houses.

Despite the above example, I don't think we need to be judging the
relative importance of TLVs, but rather the general issue that if
someone can spoof these TLVs they can influence TE decisions being made
in routers.

Regards,
Brian