On 16/10/15 07:20, Shraddha Hegde wrote: > Hi Stephen, > > Pls see inline.. > > -----Original Message----- From: Stephen Farrell > [mailto:[email protected]] Sent: Thursday, October 15, 2015 > 6:09 PM To: The IESG <[email protected]> Cc: > [email protected]; [email protected]; > [email protected]; [email protected] Subject: Stephen Farrell's No Objection > on draft-ietf-ospf-node-admin-tag-07: (with COMMENT) > > 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.) > > <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. _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
