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

yamaya <> Mon, 01 July 2013 11:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27AD321F9CF5 for <>; Mon, 1 Jul 2013 04:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aNvOxtI+vyQ8 for <>; Mon, 1 Jul 2013 04:16:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F405D21F9B52 for <>; Mon, 1 Jul 2013 04:16:55 -0700 (PDT)
Received: from ([]) by with ESMTP id 4D8TFN1.1531907; Mon, 01 Jul 2013 20:16:50 +0900
Message-ID: <>
Date: Mon, 01 Jul 2013 20:16:50 +0900
From: yamaya <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: IPsecme WG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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, 01 Jul 2013 11:17:02 -0000

Thanks for your comments, and sorry for repsonse delayed.

This shared SA model might be potentially weaker than separate SA model, as you said. But I think that, with the shared SA model, an inexpensive CPE can communicate to a large number of other CPEs simultaneously.
We have added some statements about the motivation to the I-D and updated it (draft-yamaya-ipsecme-mpsa-01).

(2013/03/12 2:25), 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
> to.

As Praveen said, CPEs find out others by BGP. He said that meshed BGP sessions causes a scale issue, but I think that it would be avoided by using Route Reflector. Using Route Refletor, end-point gateways establish one BGP session to Route Refletor.

> 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 very
> 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 connecting
> to me is for "MPSA 1" versus "MPSA 2" ? Is there any IKE association between
> nodes? Or will they just start sending me encrypted ESP for the MPSA? What if
> someone replays some MPSA encrypted traffic appearing from one node, will my
> node suddenly stop talking cleartext to it? That seems a weak authentication
> model.
> 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 connect
> 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?

In the enviroment with many CPEs it may take long time to distirubute a key to all CPEs. So "activation date" is introduced for CPEs to switch new MPSA from old one after finishing the distribution.

Auto discovery is accomplished by BGP, that session keeps to be connected between the gateway, as route reflector, and a CPE. The BGP session should be on CHILD_SA, so the SA between the gateway and CPE should kept to be.

> 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.
> Paul

Best Regards,
Arifumi Yamaya