Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC

Marc Lampo <> Wed, 20 November 2013 08:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C06521AE397 for <>; Wed, 20 Nov 2013 00:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wr6XpPl2hDvz for <>; Wed, 20 Nov 2013 00:01:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c01::22e]) by (Postfix) with ESMTP id 5461E1AE390 for <>; Wed, 20 Nov 2013 00:01:34 -0800 (PST)
Received: by with SMTP id cz12so6908399veb.19 for <>; Wed, 20 Nov 2013 00:01:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mi1EKpqwbCcKcdFDrcOy71+GLWyaxtBXZmrZVh/WTu4=; b=e9qaMgSw9KzXtXNrl2eJzich67vWnTgErZ8UL8NNsY19OKcWd5sSmpbcGbVZntz4vQ TpnUDwAWrDk/7CKBgcr2ZHJZCJz1+7+iPfuwZpWFhaixQeUsdYhZHtiDJmvm0y0ZzZcg 9Tl1KncF3nGfFuvcLy1qEwurEZCdgt+hY9isRSMIo2wnFMNrFmbUHweSpYhnuVZcKswM EwHq6BqXcBqAVYMH/tHon7OjAoR0h4tvxItUfLHq4qhLQ4deMEqnS4YHpcekPogrUXnc Rk3DT9DBYYpZ/iQ1g4G4aQVGHTMJq3/g+oMuwrwfot4x3UMS9UVi9diQZ5tVlz00fDbM V5yQ==
MIME-Version: 1.0
X-Received: by with SMTP id j1mr20692vef.27.1384934487905; Wed, 20 Nov 2013 00:01:27 -0800 (PST)
Received: by with HTTP; Wed, 20 Nov 2013 00:01:27 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 20 Nov 2013 09:01:27 +0100
Message-ID: <>
From: Marc Lampo <>
To: Lorenzo Colitti <>
Content-Type: multipart/alternative; boundary=047d7b339df9305b4604eb9730cc
Cc: Ray Hunter <>, " WG" <>
Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Nov 2013 08:01:37 -0000

This document states, for several recommendations in RFC 6092, exactly the
opposite of that document.

In addition, as I touched in my very first reaction, this draft lists a
number of threats - section 2.
But, in my opinion, none of those threats are addressed by the rules for
balanced security - section 3.1.
 (my first comment only referred to the last threat on covert channels, but
I must rephrase)

Only "unauthorised use of services" is partly addressed, by blocking access
to some ports.

The later users it might be misleading : like if implementing these
balanced security rules,
 something is done about those threats.

In reply to the question : yes, personally I would be happier if the ISP
dropped all unsolicited packets towards my network (except IPsec).
An analogy :
is the front door of your home locked when nobody is at home ?
or do you have locks on the door towards the living room, kitchen and
bedrooom (only)
 and allow free access to the bathroom ?
Perhaps proper use of the bathroom is not dangerous,
 but it the unknown visitor (ab)uses the electricity outlet in the bathroom

On Wed, Nov 20, 2013 at 7:50 AM, Lorenzo Colitti <> wrote:

> On Mon, Nov 18, 2013 at 2:25 AM, Ray Hunter <> wrote:
>> Summary: I don't have answers to my own points below, but neither does
>> this draft, so whilst I welcome the authors sharing their experiences, I
>> can't support publishing it as-is as a v6ops WG document.
>> The bottom line is that I wouldn't be happy if my own ISP adopted the
>> policy exactly as-documented in the draft.
> Would you be happier if your ISP implemented the "simple security"
> recommendations in RFC 6092 and dropped all unsolicited packets to your
> network except IPsec?
> I think we probably need something more sophisticated. And being
>> realistic, we're probably not yet ready to write it.
> So let's not throw out the baby with the bathwater then? This group exists
> to share operational experience, and that is what this draft does. It does
> not make any recommendations; even the rules it presents are examples. I
> can't see anyone construing this as a recommendation or endorsement of any
> sort.
> We published RFC 6092. Why shouldn't we publish this one? It seems to me
> that there's no real difference between this document and RFC 6092;
> fundamentally, they both simply describe a security profile without making
> any claim about whether it is a recommended profile. If anything, at least
> this one has the advantage that it was deployed before it was
> standardized...
> I support this document.
> _______________________________________________
> v6ops mailing list