Re: [IPsec] draft-yamaya-ipsecme-mpsa-00

Praveen Sathyanarayan <> Mon, 11 March 2013 18:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9E6521F8D07 for <>; Mon, 11 Mar 2013 11:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.467
X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VVd68jE3761V for <>; Mon, 11 Mar 2013 11:26:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 46FFE21F8D2D for <>; Mon, 11 Mar 2013 11:26:07 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Mon, 11 Mar 2013 11:26:07 PDT
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 11 Mar 2013 11:24:42 -0700
Received: from ( by ( with Microsoft SMTP Server id 14.1.355.2; Mon, 11 Mar 2013 11:24:41 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 11 Mar 2013 11:34:03 -0700
Received: from ( by ( with Microsoft SMTP Server id; Mon, 11 Mar 2013 18:24:41 +0000
Received: from mail56-co1 (localhost []) by (Postfix) with ESMTP id CD08BB00176 for <>; Mon, 11 Mar 2013 18:24:40 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); (null);; R:internal; EFV:INT
X-SpamScore: -24
X-BigFish: PS-24(zzbb2dI98dI9371I4015Idb82hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dh8275bhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h)
Received: from mail56-co1 (localhost.localdomain []) by mail56-co1 (MessageSwitch) id 1363026278887158_8718; Mon, 11 Mar 2013 18:24:38 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id D520C3C0084; Mon, 11 Mar 2013 18:24:38 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 11 Mar 2013 18:24:37 +0000
Received: from ([]) by ([]) with mapi id 14.16.0275.006; Mon, 11 Mar 2013 18:24:29 +0000
From: Praveen Sathyanarayan <>
To: Paul Wouters <>, IPsecme WG <>
Thread-Topic: [IPsec] draft-yamaya-ipsecme-mpsa-00
Thread-Index: AQHOHn12MjA093XUVE+V2LTszVL35ZigacGA
Date: Mon, 11 Mar 2013 18:24:29 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [IPsec] draft-yamaya-ipsecme-mpsa-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Mar 2013 18:26:09 -0000

If I understood accurately, author meant to establish mesh BGP sessions,
which would allow discovery of each other information. But IMO, this may
cause scale issue. AD-VPN is mainly to address a large VPN deployments. As
an example, say 2000 end-points are deployed. With this MESH approach,
there are (2000 - 1) BGP sessions established in each and every end-point.
 Generally, end-point gateways are small devices, which may not capable of
establishing so many BGP sessions. IMO, this is not scalable approach.
Also, even though it may not pass traffic to given end-point, it may have
to establish BGP sessions with them.

I do agree with Paul's other security concerns as well. If hacker can
establish a tunnel with gateway and get MP-SA, then all end-points are
compromised. I also agree, this draft should add more details.


On 3/11/13 10:25 AM, "Paul Wouters" <> wrote:

Regarding draft-yamaya-ipsecme-mpsa-00

The draft claims to be about "auto discovery and configuration
function". However, I don't actually see any of that in the draft. I
have no idea how nodes find out about other nodes they can talk IPsec

What I do see in the draft is a mechanism for a gateway to relay keying
material (nonces!!) for a shared IPsec SA to other nodes
after authenticating such nodes.

That raises a few questions for me:

If we want to accomplish a gateway allowing authenticated parties into a
collection of IPsec nodes, why not negotiate separate SA's? There is no
real reason to use a single shared IPsec SA session key, and it vastly
reduced the security.  One conpromised node would reveal the IPsec SA
keying material, and with that an attacker could decrypt all the traffic
between all the nodes. Plus an attacker could just add a new node to
the system (depending on the discovery/permission model that I don't
fully understand)

Why not distribute some kind of token or PSK between gateway and
endpoints, so that two endpoints can then use that to setup the parent
SA and do a proper setup of any child SAs with a unique keying material
for those nodes? As a bonus, that will keep to a much closer deployment to
the existing method. A compromised node might be able to attach itself
to the group, but it won't allow the direct compromise of any other
node-to-node traffic in the collection. Also this allows each node to
reject any proposals for IP address ranges it is unwilling to relay to
a particular node.

Furthermore, I see no discovery method in the draft that tells a node
which other nodes are available via this shared MPSA. How does a node
know it can do the MPSA to another node? It seems the draft has no
method for asking the gateway about this. Without such a discovery,
administrators will still end up having to hardcode node configuration,
which is exactly what we are trying to avoid.

While the diagrams display there can be gateway-endnode and endnode-endnode
traffic using the MPSA, I see no way how the endnode could know this. As
a node, I have traffic destined for Should I use an MPSA?

I see no correlation between SRC / DST IP addresses and the MPSA. Does this
mean any endnode can connect to any other endnode within the group and just
make up its own ranges? like <-> ? That seems like a
weak trust model. Additionally, what if I want my node to be in more then
one MPSA group ? Can I have two MPSA's ? How would I know a node is
to me is for "MPSA 1" versus "MPSA 2" ? Is there any IKE association
nodes? Or will they just start sending me encrypted ESP for the MPSA? What
someone replays some MPSA encrypted traffic appearing from one node, will
node suddenly stop talking cleartext to it? That seems a weak

I find the terminology for "rollover time1" (ROLL1) and "rollover time2"
(ROLL2)  confusing, as it seems to actually be more representative of an
"expiration date" and an "activation date". It seems to also overlap with
"lifetime" (LIFE). Doubly so as the expiration for ROLL1 has to be related
to the start of ROLL2. So we know when to roll, but we still need to
to the gateway to get the keying material? So why not just limit everything
to an expiration time for when the nodes have to contact the gateway again
for the new MPSA keying material?

The gateway is supopsed to rekey, but that can be difficult with clients
behind NAT. Since the gateway informed the clients about the lifetimes,
why not let the clients reconnect?

So in short:

- Distribute authentication information/permission, not encryption material
   (IKE SA's and traffic selectors are needed)
- Devise a mechanism to obtain a list of active nodes or a method
   to ask the gateway if a certain node is avaialble via MPSA or not.
- Reduce the information sent to the minimum required.
- Agree on some kind of scope of IP addresses for the MPSA

As it stands, I don't really see myself implementing this. There are
too many unanswered security concerns, and it does not have enough
discovery features in it for my needs.


IPsec mailing list