Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08

"Sri Gundavelli (sgundave)" <> Mon, 27 July 2015 16:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7749E1B303F; Mon, 27 Jul 2015 09:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4WriZOQ7j9Ka; Mon, 27 Jul 2015 09:24:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BFE41B3042; Mon, 27 Jul 2015 09:24:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9076; q=dns/txt; s=iport; t=1438014278; x=1439223878; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+diT8OcaScKsUUeYXbpkxtMKl8obxbsD8RU3TIbk9JY=; b=fta5vSZjCgmTcASkXFAwyeLRwr+ZBy2g8XZUtIOmNpdD++ByEj24OvUy dvNdTcy8Ai5qjfN0uYg5T27k3DICD7M1ZXnDivUHpV+YsimON+gAqs1bW z/MpqKxSTbP7ko5XgnlmtCQSOaelDpYDYAq2jubSNxX9Xc8KlxE7Dnkf6 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,555,1432598400"; d="scan'208,217";a="172765556"
Received: from ([]) by with ESMTP; 27 Jul 2015 16:24:37 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t6RGObqi026267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 16:24:37 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 11:24:37 -0500
From: "Sri Gundavelli (sgundave)" <>
To: "Bernie Volz (volz)" <>, Stephen Farrell <>, Catherine Meadows <>
Thread-Topic: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08
Thread-Index: AQHQr1cxQgFsakfaFEigKP+HYJIb8p3U2DaAgAB3gwCAABDgAIAABGMAgBosQAA=
Date: Mon, 27 Jul 2015 16:24:36 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D1DBA7071CD95Csgundaveciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2015 16:24:40 -0000

Hi Stephen /Catherine,

Please lets us know if this text is sufficient to resolve this comment.

Slightly tweaking the text per Bernie’s comment. Now including IPsec reference.

"The information elements that this draft is exposing is the client’s access-network information. These pertains to the access network to which the client is attached, such as Access Technology Type (Ex: WLAN, Ethernet…etc), Access Point Identity (Name, BSSID), Operator Id/Realm. Exposing these information elements to an eavesdropper has no implication on the end-user security. But, in deployments where this information is considered secure and when such threat cannot be mitigated using IPsec [RFC4301] or other security protocols, then the administrators have to consider disabling the capability specified in this document on the DHCP entities."


On 7/10/15, 10:43 AM, "Bernie Volz (volz)" <<>> wrote:

I am not aware of such data. My guess is that most SPs place this kind of traffic in what they hope to be an isolated network (i.e., behind firewalls, ...).

Also, much of this data is pretty easy to find anyway ... SSIDs are mostly broadcast (or easy to snoop for), which mobile operator you use is probably discoverable in seconds (heck I bet you’d answer if I asked, or if I had your number a google query would probably tell me ...). So, I'm not really sure how critical this information tends to be. But, yet protecting it is better than not protecting it. But I think steps should have been taken for the other data in DHCP (relay to server).

- Bernie

-----Original Message-----
From: Stephen Farrell []
Sent: Friday, July 10, 2015 1:28 PM
To: Bernie Volz (volz); Sri Gundavelli (sgundave)
Subject: Re: [secdir] secdir review of draft-ietf-dhc-access-network-identifier-08


On 10/07/15 17:27, Bernie Volz (volz) wrote:
IPsec should also hide this information from pervasive monitoring
(though how much IPsec is in use is an open question). Note also that
as this is relay to server (or relay to relay) communication, one
would hope that most SPs have taken measures to 'secure' this traffic
either by using IPsec or VPNs.

Do we have any data as to whether or not such protection does get deployed? I'd not be surprised if there's not much public, but if there were it'd be good to know.

I also believe we have had reported cases where pieces of the network infrastructure of various kinds of operator have been targeted for PM purposes, so while yes, it is really strange that someone would want to do that, it seems to be a real, and not notional, threat.