Re: [secdir] Secdir review of draft-ietf-v6ops-ipv6-roaming-analysis-05

Jouni Korhonen <> Thu, 02 October 2014 07:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 461481A0107; Thu, 2 Oct 2014 00:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sVa94eWPycQR; Thu, 2 Oct 2014 00:15:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB8EF1A0121; Thu, 2 Oct 2014 00:15:30 -0700 (PDT)
Received: by with SMTP id q1so1786543lam.22 for <multiple recipients>; Thu, 02 Oct 2014 00:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=l34eSlwTFhZU9FTojAjcMOWXGAZ2k8NjyRJhhjWe1OM=; b=Aom8NF/P7TmDOFm3Xc+4MJ7/teVNnBx6in2RDbXtH+v2Wo2k9E10rLRP0hkpry24o4 7hyQQlYtEIiRpxkAMbGAUzzCTwMBuIV5dw1Xp0kH8kd1lyvRpw9nGnwVd4U77XRKVi3x 4ta3VZx+6fBdDUivq6iIEZxM3uOhJl7Kb65i3kmyi/pod0XwFVlnFCGIb4DRw0hNWLap 6hPQU4tBuFYCGBhNBQv3pGkv5f3w2iFbLpv3gtqKKeR3x/d+3rAqnWKrL1pUEE1Rj+m6 VK1T+0yZk9bKBHkIFkzpOyR2vNDQxMdUrvASnNhDafsoeKnsCGvgm4+WmD2niqJoRFtH ZtuA==
X-Received: by with SMTP id p8mr61555944lap.32.1412234129150; Thu, 02 Oct 2014 00:15:29 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id d5sm1265382lae.11.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 00:15:28 -0700 (PDT)
Message-ID: <>
Date: Thu, 02 Oct 2014 10:15:31 +0300
From: Jouni Korhonen <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <>, "<>" <>, IESG <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] Secdir review of draft-ietf-v6ops-ipv6-roaming-analysis-05
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: Thu, 02 Oct 2014 07:15:34 -0000


Thank you for the review. See quick responses inline.

9/30/2014 7:37 AM, Joseph Salowey (jsalowey) kirjoitti:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> In summary I believe the document is ready.  It does make reference to security considerations IPV6-3GPP RFC 6459 which is appropriate. I have a few observations below.
> 1) There is a brief discussion of home routed an local breakout modes which determine
> how the user's traffic is routed.  This could potentially have privacy implications,
> however I do not think this is the subject of the document so I don't think additional
> privacy considerations are needed.  The one exception may be if an attacker can force
> the selection of one of these options.  This did not appear to be the case from the
> document, but I did not follow all the 3GPP specifics.

The end user does not really have a power to affect the selection of 
gateways the networks does. There might be limitted power for the 
subscriber if he/she is able to select between APNs but then again to 
which gateway (home or visited) the APN resolves to is entirely up to 
the network to decide.

> 2) Some of the failure modes  consume more network resources.  If these modes can be
> externally manipulated then it may be possible for a denial of service attack.  This
> did not appear to be the case from the document, but I did not follow all the 3GPP
> specifics.

It is a common failure case that a mistypes APNs and etc configurations 
bombard the network - and these would more or less equal the attack that 
the above refers to from the network point of view. Modern gateways are 
well protected against stuff like this by offering sensible default if 
the mobile device starts sending garbage. These are mainly 
implementation details and not typically covered in specs.

Another thing is mobile device implementations intentionally breaking 
specs to achieve some shortcut or power saving etc (the network has to 
survive those anyway). All these glorified highend mobiles are (or were) 
doing these in the expense of the network.. obviously networks have now 
been designed to take the hit.

- Jouni

> Cheers,
> Joe