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

Stephen Farrell <> Fri, 16 October 2015 13:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1CC181A1B07; Fri, 16 Oct 2015 06:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fk59uLh0SxLR; Fri, 16 Oct 2015 06:25:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4481C1A1B00; Fri, 16 Oct 2015 06:25:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 117AFBEDC; Fri, 16 Oct 2015 14:25:05 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9ZqLltqD1PYN; Fri, 16 Oct 2015 14:25:04 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 56F0DBE5B; Fri, 16 Oct 2015 14:25:04 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1445001904; bh=nz35pULvaSRxf55ffcJRPEFNJI5/T2qUzGGEiITk62k=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=APN8Ly/V6h/Ni4gE0Mt2VDu+dkp1QNe0DsWfGwhmnX/T64SbtYRREsYdp+92FV1Rt zaHvtiwqiP7TvRUDBBxgwHZGHoippd9Crd3mjnLpqE2suYyWZPst56Uvzms4pEErGe lq95R4utxDr0mU4pS/lTdUrFms2zYiavyyx1IeVg=
To: Shraddha Hegde <>, The IESG <>
References: <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Fri, 16 Oct 2015 14:25:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-node-admin-tag-07: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Oct 2015 13:25:08 -0000

On 16/10/15 07:20, Shraddha Hegde wrote:
> Hi Stephen,
> Pls see inline..
> -----Original Message----- From: Stephen Farrell
> [] Sent: Thursday, October 15, 2015
> 6:09 PM To: The IESG <> Cc:
>; 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
> for more
> information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here: 
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> - 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.