Subject: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-node-admin-tag-07: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 15 Oct 2015 05:39:26 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ospf-node-admin-tag-07: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-ospf-node-admin-tag/

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

- I think Alavaro and Brian make some good points. I'll be
interested in how that discussion turns out.

- Good to see that you recognise that even opaque tag values
can expose sensitive information (the attacker isn't limited
in how they are allowed interpret what they see). However,
given that we recognise that confidentiality ought be provided
sometimes, isn't there an onus on us to actually provide some
usable way to get that service? If so, then who is looking at
that problem? If not, then why is that acceptable? (This isn't
a discuss as I don't think there is any PII or similar
information being transferred, and the confidentiality
requirement here really relates to network topology etc. But
please do correct me if one of these tags could be PII-like
and I'll make this a discuss if that's better.)

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 16 Oct 2015 06:20:40 +0000

Hi Stephen,

Pls see inline..

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, October 15, 2015 6:09 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Stephen Farrell's No Objection on draft-ietf-ospf-node-admin-tag-07: (with COMMENT)

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

- I think Alavaro and Brian make some good points. I'll be interested in how that discussion turns out.

- Good to see that you recognise that even opaque tag values can expose sensitive information (the attacker isn't limited in how they are allowed interpret what they see). However, given that we recognise that confidentiality ought be provided sometimes, isn't there an onus on us to actually provide some usable way to get that service? If so, then who is looking at that problem? If not, then why is that acceptable? (This isn't a discuss as I don't think there is any PII or similar information being transferred, and the confidentiality requirement here really relates to network topology etc. But please do correct me if one of these tags could be PII-like and I'll make this a discuss if that's better.)

<Shraddha> OSPF in itself does not have  ways to provide confidentiality but in cases where it is needed OSPF can run on top of IPSEC tunnels which can encrypt the OSPF control packets. IPSEC mechanisms can also be applied to OSPF packets using RFC 4552 for OSPFv3. Adding below text to the draft.

Node administrative tags may be used by operators to indicate geographical location or other sensitive information.
 As indicated in <xref target="RFC2328"/> and <xref target="RFC5340"/> OSPF authentication mechanisms do not provide 
 confidentiality and the information carried in node administrative tags could be leaked to an IGP snooper.
Confidentiality for the OSPF control packets can be achieved by either running OSPF on top of IP Security (IPSEC) tunnels or 
by applying IPSEC based security mechanisms as described in <xref target="RFC4552"/>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Oct 2015 14:25:04 +0100

On 16/10/15 07:20, Shraddha Hegde wrote:
> Hi Stephen,
> 
> Pls see inline..
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Thursday, October 15, 2015
> 6:09 PM To: The IESG <[email-masked]> Cc:
> [email-masked]; [email-masked];
> [email-masked]; [email-masked] Subject: Stephen Farrell's No Objection
> on draft-ietf-ospf-node-admin-tag-07: (with COMMENT)
> 
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
> information about IESG DISCUSS and COMMENT positions.
> 
> 
COMMENT:
> - Good to see that you recognise that even opaque tag values can
> expose sensitive information (the attacker isn't limited in how they
> are allowed interpret what they see). However, given that we
> recognise that confidentiality ought be provided sometimes, isn't
> there an onus on us to actually provide some usable way to get that
> service? If so, then who is looking at that problem? If not, then why
> is that acceptable? (This isn't a discuss as I don't think there is
> any PII or similar information being transferred, and the
> confidentiality requirement here really relates to network topology
> etc. But please do correct me if one of these tags could be PII-like
> <Shraddha> OSPF in itself does not have  ways to provide
> confidentiality but in cases where it is needed OSPF can run on top
> of IPSEC tunnels which can encrypt the OSPF control packets. IPSEC
> mechanisms can also be applied to OSPF packets using RFC 4552 for
> OSPFv3. Adding below text to the draft.
> 
> Node administrative tags may be used by operators to indicate
> geographical location or other sensitive information. As indicated in
> <xref target="RFC2328"/> and <xref target="RFC5340"/> OSPF
> authentication mechanisms do not provide confidentiality and the
> information carried in node administrative tags could be leaked to an
> IGP snooper. Confidentiality for the OSPF control packets can be
> achieved by either running OSPF on top of IP Security (IPSEC) tunnels
> or by applying IPSEC based security mechanisms as described in <xref
> target="RFC4552"/>
> 

That's good text, but is it realistic to run OSPF over IPsec in a
way that'll prevent snooping but not get in the way of routing? I'd
much prefer we admit there can be an issue for which we don't have
a good answer instead of us pretending there's an answer when we
know or suspect the mitigation won't work in practice.

So unless you know that OSPF can be run in practice over IPsec in
a way that'll mitigate this I'd say removing the last sentence would
be much better.

Cheers,
S.