Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02

Stephen Farrell <> Fri, 29 April 2016 09:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66B5912D7B1; Fri, 29 Apr 2016 02:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Status: No, score=-5.297 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o3eieQMoOPZH; Fri, 29 Apr 2016 02:36:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00DDA12D77B; Fri, 29 Apr 2016 02:36:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26B5CBE56; Fri, 29 Apr 2016 10:36:45 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g2WLThcwYjox; Fri, 29 Apr 2016 10:36:45 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 86C50BE38; Fri, 29 Apr 2016 10:36:44 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1461922604; bh=feXYUDWPjG79PmBZ6ORVOTzBjYomVS1iBSzHEOApUU8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=XyREjp2+GB1/8XSAR0bJPSB9KA9vWYGmF4QsnQ0tU1Pxp/AeQIYkpN4ZpLJVzrzhk OUBb4/RjMiuPODKS8XkE3NPXfi/IA4uZ+w/SagT2ukGEtVp38AXnG3+KVBEjNRTEvG +gcvAPxJKvXpR/c8ET/9MybqEsow7dOUaF+lV/K8=
To: Stewart Bryant <>, Phillip Hallam-Baker <>
References: <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Fri, 29 Apr 2016 10:36:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030809040602080904020706"
Archived-At: <>
Cc:, "Andrew G. Malis" <>, "" <>, "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Apr 2016 09:36:49 -0000

Hi all,

On 29/04/16 10:19, Stewart Bryant wrote:
> I think we need to wind this discussion way back.

I agree. I see a couple of things happening in this
discussion that have happened before and will happen

1) a secdir reviewer finds very little in the way of
security mechanism specified for important routing
protocols when trying to understand some minor update
to something

2) the reviewer comments on that saying: "hey, this
whole thing is pretty insecure looking, what's up?
e.g. you could do <badthing-n> here."

3) authors/chairs/WG participants say "it's ok, these
are well managed networks, if you can do <badthing-n>
then there are much worse things you could do" and
maybe over-react a bit as well, fearing that some
security mafia are going to try force them to pretend
to add crypto to loads of stuff

4) n++; goto 2 (a few times;-)

I'm not sure how we break that cycle to be honest,
at least not for we==IETF participants.

I doubt it's likely that we can ensure that secdir
reviewers are all familiar with MPLS, PW, etc etc.
I equally doubt that routing folks will (for both good
and perhaps less good reasons) define, implement
and deploy the kind of security mechanisms that'd
be needed to avoid secdir reviewers being surprised.

I suspect what'll eventually happen is that outside
the IETF context, routing folks and/or their customers
will decide that boundary security is just no longer
good enough by itself and will end up having to do a
load of work to address that. And some bits of that
work will end up being IETF stuff. (One would hope
that all the SDN and similar bits of work are going
to head down that path and not try to depend just on
boundary security for example.)

In the meantime, I think we just repeat the above
loop now and then.