Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Sep 2012 09:31:23 -0700

This appeared on the list over two weeks ago and it has received no comments since. This is supposed to be the WG's main work item, folks.

--Paul Hoffman

On Aug 23, 2012, at 9:02 AM, Stephen Hanna <[email-masked]> wrote:

> Vishwas and I have updated the AD VPN Problem Statement
> and Requirements draft to address the comments received
> on the previous version and remaining comments from
> earlier email discussions. The new version is available at
> 
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem
> 
> A summary of the changes in this version is included at
> the end of this message.
> 
> Please review this document and provide any comments on
> the existing requirements or suggestions for new ones.
> 
> For requirement 3, Vishwas will be starting an email
> thread soon so that the WG can discuss what this text
> means, whether we want to keep it, and how it can be
> made clearer.
> 
> Thanks,
> 
> Steve
> 
> ------------
> 
> Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt
> 
> * Changed draft name from p2p-vpn to ad-vpn.
> 
> * Added a paragraph for each requirement, explaining how
>  that requirement is driven by the use cases.
> 
> * In requirement 1, defined what we mean by minimizing
>  configuration changes.
> 
> * In requirement 2, explained that this requirement implies
>  that SPD entries and other configuration based on peer
>  IP address will need to be automatically updated when
>  the peer's IP address changes.
> 
> * Split requirement 4 into two requirements (now 4 and 5).
> 
> * In requirement 6 (formerly 5), explained what we mean
>  by "easy handoff of sessions": avoid TCP session breakage
>  and packet loss, when possible.
> 
> * In requirement 8 (formerly 7), acknowledged the difficulty
>  of handling cases where gateways are behind NATs or where
>  two endpoints are both behind separate NATs. In those cases,
>  we may need to use workarounds such as port forwarding by
>  the NATs or falling back to a hub and spoke architecture.
> 
> * Added new requirement 9 around manageability.
> 
> * Added new requirement 10 around cross-organization use.
> 
> * Added new requirement 11 saying that administrators should
>  be able to limit topologies for security and other reasons.
> 
> * Fixed typos and other minor wording issues.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 8 Sep 2012 22:23:18 +0300

> This appeared on the list over two weeks ago and it has received no comments since. This is supposed to be the WG's main work item, folks.

OK.

Section 4.1:

Point #1: While less configuration required is better, I would like there to be some absolute requirements. Like, changing or adding a spoke requires no changes to other spokes. Or changing any node does not require changing any other nodes where the static configuration does not include that node.

Speaking of which, I think a good criterion for evaluating proposals is the amount of required static (or "manual") configuration.

Point #3: What is "tunnel binding"?

Point #4 is unclear. If spokes talk to other spokes, in what way are they spokes? Sounds like a mesh to me. If you mean that the administrator(s) begin by statically configuring a star topology, and it automagically morphs into a mesh, this should be said explicitly.

Point #6: I'm not sure what a handoff is. If it's a single host moving from behind one peer to behind another peer, I don't see how this can be required. VPN gateways are often combined with stateful firewalls, which typically refuse to allow a TCP connection to proceed. 

Point #9: I think there's an expired draft for an IPsec MIB. But that's not what I meant in Vancouver. We are adding dynamic changes to the configuration. These changes should be logged and reported to facilitate trouble-shooting. With static configuration, if you haven't touched the configuration and things stopped working, you can look at gateways failing, at network errors, expired certificates, or any number of other issues that administrators know about and can look for. A dynamically changing configuration is a new possible source for errors, one that is currently not reported. So if gateway A believes that packets to host H should be forwarded through gateway B, but gateway B applies a DROP rule to all such packets, we need reporting of the configuration changes on both gateways to see how this thing happened.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 10 Sep 2012 15:25:09 +0300

Paul Hoffman writes:
> This appeared on the list over two weeks ago and it has received no
> comments since. This is supposed to be the WG's main work item,
> folks. 

My comments:

> 2.2.  Gateway-to-Gateway AD VPN Use Case
...
>    The spoke gateways can themselves come up and down, getting different
>    IP addresses in the process, making th static configuration
					 ^^
Typo.

> 3.2.  Star Topology
...
>    This solution however does not work when the spokes get dynamic IP
>    address which the "hub gateways" cannot be configured with.  

I think star topology works fine with dynamic IP addresses. You just
need to make sure that the spokes are the entities which brings up the
link, i.e. immediately when they boot up they put up the IPsec link
and keep it up all the time. There is other identities in the IPsec
world than IP-addresses...

I would remove the whole sentence.

>    bandwidth.  A single packet in the hub-and-spoke scenario can be
>    encrypted and decrypted three times.  It would be much preferable if

In the pure hub-and-spoke model I cannot really see more than two
times, one from the spoke to hub, and second time from the hub to
another spoke. If there is hub to hub links also then it is not pure
hub-and-spoke scenario anymore. I would replace the "three" with
"multiple". I myself really had to read the first paragraph of this
section again to notice that you talk there that this section says
there can be multiple gateways selected as hub gateways.

> 4.1.  Gateway and Endpoint Requirements
...
>    2.  Gateways and endpoints MUST allow IPsec Tunnels to be setup
>    without any configuration changes, even when peer addresses get
>    updated every time the device comes up.

This is unclear for me. Does that mean that anybody can connect to the
gateway and the gateway MUST allow IPsec Tunnels to be setup without
any configuration changes (like adding authentication credentials?). I
do not think so.

I think this needs to be clarified. Also endpoints do require
configuration changes before they can first time connect to the AD
VPN, for example you need to insert the credentials and most likely
also point at least one gateway for them to fetch rest of
configuration from them.

If this is just trying to say that already configured devices in the
AD VPN MUST be able to connect to any other configured device in the
AD VPN at any time, even when the IP addresses are not known
beforehand, then I think it should be said differently.

Anyways I am not sure what this is trying to say.

>    This implies that SPD
>    entries or other configuration based on peer IP address will need to
>    be automatically updated, avoided, or handled in some manner to avoid
>    a need to manually update policy whenever an address changes.

This is much more clear, and I think this most likely means that the
first paragraph was trying to say that already existing AD VPN members
should be able to connect other AD VPN members even when their
IP-addresses are not static.

Next question is how does the one member know to which address connect
to if also the destination member has changing IP address? And how to
punch holes to NATs that might be between them.

>    3.  Gateways MUST allow tunnel binding, such that applications like
>    Routing using the tunnels can work seamlessly without any updates to
>    the higher level application configuration i.e.  OSPF configuration.

I have no idea what this requirement means. What is "tunnel binding"?
Where does this requirement come? Which use case drives this?

>    4.  In a hub-and-spoke topology, spoke gateways and endpoints MUST
>    allow for direct communication with other spoke gateways and
>    endpoints.

Hmm... why are you listing here spokes and endpoints as separate
entries. In the terminology I understood spoke also includes
endpoints? 

>    5.  One spoke MUST NOT be able to impersonate another spoke.

If spoke does not imply endpoints, then we should say that this also
applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able
to impersonate another spokes or endpoints.

What about hubs? Are they allowed to impersonate other hubs? I assume
yes, but then next question comes are hubs allowed to impersonate as a
spoke or endpoint? Is there any requirement that when endpoint makes
direct connection to other endpoint it knows that there cannot be any
other parties listening on the link? If there is such requirement then
also the hubs are not allowed to impersonate endpoints, but on the
other hand if we use CA infrastructure, then the CA can always issue
certificate allowing this kind of impersonation.

>    6.  Gateways SHOULD allow for easy handoff of sessions in case
>    endpoints are roaming, even if they cross policy boundaries.  This
>    means that TCP session breakage and packet loss should be avoided,
>    when possible.
> 
>    This requirement is driven by use case 2.1.  Today's endpoints are
>    mobile and transition often between different networks (from 4G to
>    WiFi and among various WiFi networks).

This cannot come from case 2.1, as that is endpoint to endpoint, so
there is no gateway at all there. I would expect this would come from
2.3 i.e. the endpoint to gateway use case.

Or does this mean gateways should allow handoff from the
endpoint-gateway-endpoint to direct endpoint-endpoint link without
breaking TCP sessions?

>    8.  Gateways and endpoints MUST be able to work when they are behind
>    NAT boxes.  However, it is especially difficult to handle cases where
>    gateways are behind NATs and where two endpoints are both behind
>    separate NATs.  In those cases, workarounds MAY be used such as port
>    forwarding by the NAT or detecting when two spokes are behind
>    uncooperative NATs and using a hub in that case.
> 
>    This requirement is driven by use cases 2.1 and 2.2.  Endpoints are
>    often behind NATs and gateways sometimes are.  IPsec should continue
>    to work seamlessly regardless, using AD VPN techniques whenever
>    possible and providing graceful fallback to hub and spoke techniques
>    as needed.

Does this also include discovery of the addresses? How about if we
have two endpoints talking to each other and one of the nat boxes is
restarted and one peers IP-address changes, and as the NATs are
restricted nats, which means they cannot connect to each other at all
after that without the help of the 3rd party. Also the 3rd party
cannot connect to either one of them, thus the recover must then start
from the endpoints so both of them connect to this 3rd party (hub) to
recover from the situation. 

>    9.  Changes such as establishing a new IPsec SA SHOULD be reportable
>    and manageable.  However, creating a MIB or other management
>    technique is not within scope for this effort.
> 
>    This requirement is driven by manageability concerns for all the use
>    cases, especially use case 2.2.  As IPsec networks become more
>    dynamic, management tools become more essential.

I would rule configuration MIB out of the scope, but I would actually
think it would be good idea to make reporting and statistics MIB. We
really need one in the IPsec, and this is effort I think we should
take here in ipsecme also for normal IPsec devices.

I am sure we are still missing some requirements, but thats my
comments for the existing requirements. I need to think bit more what
other requirements we might have.
-- 
[email-masked]

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 11 Sep 2012 20:04:09 -0700

Hi Tero/ Yoav,

Thanks for your great comments. We are discussing this internally and will
get back to you in a few days.

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 14 Sep 2012 15:16:36 -0700

Hi Yoav,

My replies below. Thanks a lot for your thoughtful comments and I am sorry
for the delays.

Section 4.1:
>
> Point #1: While less configuration required is better, I would like there
> to be some absolute requirements. Like, changing or adding a spoke requires
> no changes to other spokes. Or changing any node does not require changing
> any other nodes where the static configuration does not include that node.
>
> Speaking of which, I think a good criterion for evaluating proposals is
> the amount of required static (or "manual") configuration.
>
VM> I agree we need absolute requirements. The point we were trying to
stress was that though we know not having any changes in some cases may not
be possible it should be a requirement to minimize the changes in
configuration.

I will look at the various cases as you suggest and then put in more exact
requirements.

> Point #3: What is "tunnel binding"?
I have heard similar concerns from Steve Hanna on the requirements too. The
idea here is that we should allow applications like OSPF, to work over the
tunnels irrespective of the end point addresses.Let me know if I am clearer.

>
> Point #4 is unclear. If spokes talk to other spokes, in what way are they
> spokes? Sounds like a mesh to me. If you mean that the administrator(s)
> begin by statically configuring a star topology, and it automagically
> morphs into a mesh, this should be said explicitly.
>
This requirement comes from the way Enterprise WAN architecture is. The
branches connect to the data centers in a Hub-and-Spoke topology using
IPsec tunnels. However spokes are optionally and temporarily allowed to
connect to each other for traffic such as voice etc which does not gain
from taking an extra hop to the data center.

I will clarify the point.

> Point #6: I'm not sure what a handoff is. If it's a single host moving
> from behind one peer to behind another peer, I don't see how this can be
> required. VPN gateways are often combined with stateful firewalls, which
> typically refuse to allow a TCP connection to proceed.
>
It is for that purpose the draft says the protocol should avoid packet loss
when possible. If there are external factors like firewalls, they need to
be dealt with separately.

>
> Point #9: I think there's an expired draft for an IPsec MIB. But that's
> not what I meant in Vancouver. We are adding dynamic changes to the
> configuration. These changes should be logged and reported to facilitate
> trouble-shooting. With static configuration, if you haven't touched the
> configuration and things stopped working, you can look at gateways failing,
> at network errors, expired certificates, or any number of other issues that
> administrators know about and can look for. A dynamically changing
> configuration is a new possible source for errors, one that is currently
> not reported. So if gateway A believes that packets to host H should be
> forwarded through gateway B, but gateway B applies a DROP rule to all such
> packets, we need reporting of the configuration changes on both gateways to
> see how this thing happened.
>
I agree this is a good requirement and I will update the draft with the
same.

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 14 Sep 2012 15:39:42 -0700

Hi Tero,

Thanks a lot for your comments. My comments inline with a "VM>" prefix.

> >    IP addresses in the process, making th static configuration
VM> Perfect.

> VM> I think what we need to talk here is that in case IP address is used
as an identifier, we need to make sure that it works even as the IP address
changes or we can put it that IP address should not be ever used as
identifiers in such cases.

> there can be multiple gateways selected as hub gateways.
OK. We can replace with multiple I agree it could even be more than 3 in
some cases.

> Anyways I am not sure what this is trying to say.

VM> In my view if the first time a hub is connected to a spoke we will need
to do some configuration for sure, however as we add other similar spokes
(could be based on template), we would require no configuration at the Hub
end for each spoke added. Let me know if I am clear here, I can update the
document with this.

> punch holes to NATs that might be between them.
VM> These are the exact questions we need to answer with the protocol
solution in my view.

> Where does this requirement come? Which use case drives this?
VM> Do let me know if the mail to Yoav makes it any clearer?

> entries. In the terminology I understood spoke also includes
VM> I agree good point. Will update.

> certificate allowing this kind of impersonation.

VM> In my view for the ADVPN case Hubs and spokes have permanent
connections. Spokes may have temporary connections with other spokes and in
such cases the temporary credentials should not allow any impersonation at
all. That was the intent. Let me discuss this with Steve on how to resolve
the same.

> endpoint-gateway-endpoint to direct endpoint-endpoint link without
VM> The intent was the first paragraph you mention, but I do not see any
reason we should now allow for a direct connectivity either as you mention
in the second paragraph.

> recover from the situation.
VM> I think the idea here is that spokes being behind NAT's, and the
solution should allow for a tunnel setup between them. There can be
external factors however like firewall/ NAT etc which may have cause issues
and need to be dealt with seperately.

> VM> I agree with what Yoav said on this. I agree we should allow for
logging/ tracking dynamic changes. Let me discuss with Steve on whether we
should add having a MIB as a requirement for the same.

> other requirements we might have.
VM> I would love to hear such requirements.

Thanks,
Vishwas

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 Sep 2012 14:50:22 +0300

Vishwas Manral writes:
> I think what we need to talk here is that in case IP address is used

There is quite big difference "cannot be configured with" and "cannot
use IP-addresses as identifiers". And I agree IP addresses should not
be used as identifiers in these cases, but that actually DOES NOT
prevent it working. The ID is just identifier that can be used for
policy lookup, and the RFC5996 says:

							When using the
   ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
   does not require this address to match the address in the IP header
   of IKEv2 packets, or anything in the TSi/TSr payloads.  The contents
   of IDi/IDr are used purely to fetch the policy and authentication
   data related to the other party.

So even when the spokes have dynamic IP addresses they can use
whatever ID_IPV4_ADDR/ID_IPV6_ADDR they like to identify themselves to
the other end. For example they could always use their internal
IP-address, i.e. something like 10.22.8.1 when this device is
responsible for the traffic to 10.22.8.0-10.22.12.255, or it could use
IP address of 0.0.0.1 as this is first gateway and second gateway
could use 0.0.0.2 etc... Both of those are completely legal in RFC5996
sense, but neither of them might not be good idea in practice.

> end for each spoke added. Let me know if I am clear here, I can update the

I would expect that adding new spoke to hub only requires initial
configuration in the newly added spoke, and MAY require configuration
changes in the hub where the spoke is connected to, but SHOULD NOT
require configuration changes to the other hubs than the one where the
spoke was connected to, and MUST NOT require configuration changes in
other spokes.

Or something like that for the adding new spoke to the AD VPN. To add
new hub it might require more changes, i.e. adding new hub to the AD
VPN do require initial configuration in the newly added hub, and MAY
also require configuration changes to the other hubs, and MAY also
require configuration changes to the spokes connecting to this new
hub, but SHOULD NOT require any configuration changes to the spokes
connected to the other hubs.

Actually the current definition in the section 1.1 says:

   Hub - The central point in a star topology, generally implemented in
   a gateway.

meaning, there can be only one hub. And I just wonder how can hub not
be a gateway? I think it must always be a gateway, i.e. it always
protect traffic flowing through the device, otherwise it is not hub
it is server (and outside the scope of the AD VPN).

Perhaps we should expand this and define several different types of
devices:

   Hubs - The central point in a star topology, or one of the central
	  points in the mesh style VPN, i.e. gateway where multiple
	  other hubs or spokes connect to. The hubs usually forward
	  traffic coming from encrypted links to other encrypted
	  links, i.e. there is no devices connected to it in clear.

   Spoke - The edge devices in the a star topology, or gateway which
	   forwards traffic from multiple cleartext devices to other
	   hubs or spokes, and some of those other devices are
	   connected to it in clear (i.e. it encrypt data coming from
	   cleartext device and forwards it to the AD VPN).

   Endpoint device - A device that implements IPsec for its own
		     traffic, but does not act as a gateway.

   Cleartext device - A device that does rely on the spokes to protect
		      its traffic. Cleartext device might implement
		      IPsec, but does not use it in currect setup. 

I.e. we should define that there are cleartext devices which talk in
clear to the spokes, which encrypt the traffic and forward it either
to hubs, other spokes, or endpoints, these are devices like those in
the branch office network, which use spokes as their encryption
providers.

Then there is endpoint devices which take care of their own
encryption, and connect directly to the spokes, hubs and other
endpoints, but do not connect directly to the devices behind spokes.
Note that endpoint can move to be cleartext device if it moves to
network that is already protected by spoke. In the same way cleartext
device can move to be endpoint device if it moves out from the network
protected by the spoke.

Those two are the end user devices, i.e. those devices where the user
itself is. The spokes and hubs are just network devices forwarding
traffic.

Those definations might make things a bit more clear, especially when
we are talking about the required configuration changes. I.e. we do
not want to have any changes to any other Endpoint or cleartext
devices than what we are modifying now (adding, removing), we may have
changes to the neigbour spokes and hubs, but we should not have any
changes to spokes, or hubs further away.

> These are the exact questions we need to answer with the protocol
> solution in my view.

I meant to say is that requirement that it should work in such setup
too, or do we just say that there is no such requirement, and on end
of the connection must have static ip-address.

Also talking about NATs which classes can be behind NAT?

I assume we do require that endpoint devices MUST be able to be behind
NAT. Cleartext devices does not matter, as they do not do IPsec
themselves. Do we require that spokes also can be behind NATs? What
about hubs?

I would expect that spokes can be behind NAT, so we should probably
require that, but I am not sure if the hubs themselves will ever be
behind NAT, and it would make things much easier if we say that there
is no requirement to support setups where hubs are behind NATs. This
would solve the problem that when new spoke is added and it is trying
to fetch to configuration, it knows what IP address to use as the
IP-address of the hub can be configured to it... If all the hubs have
dynamic IP-addresses things get really complex...

> Do let me know if the mail to Yoav makes it any clearer?

Not really. I still do not understand what you mean by tunnel binding.  

> I agree good point. Will update.

Actually I think it would be easier if we make bigger changes to the
terminology, like we I proposed earlier. I.e. define roles of hub and
spokes better, and not tie them to the star-topology, like we
currently do. And in my version the spokes does not include endpoints,
as endpoints do not have any cleartext devices behind them. 

> In my view for the ADVPN case Hubs and spokes have permanent
> connections.

This is not specified anywhere. If such requirement exists, we need to
list it as requirement. I for example do not agree on that. I think
hub-to-hub connections should be permanent, but hub-to-spoke
connections might not be permanent, as one spoke might decide it is
forwarding stuff so much to some other hub, that it might be better to
connect directly to that hub, and only use local hub for more local
traffic. 

> Spokes may have temporary connections with other spokes
> and in such cases the temporary credentials should not allow any
> impersonation at all. That was the intent. Let me discuss this with
> Steve on how to resolve the same.

Ok.

> The intent was the first paragraph you mention, but I do not see any

I am lost now. I think this requirement needs to be specified more
clearly, so I can understand what is mean by it.

> I think the idea here is that spokes being behind NAT's, and the

The original requirement talked about gateways and endpoints, and
gateways also includes hubs. I think we really need to define those
roles more clearly.
-- 
[email-masked]

---

From: "Ulliott, Chris" <[email-masked]>
Date: Tue, 18 Sep 2012 01:11:21 +0100

Classification:UNCLASSIFIED

Paul,

I'm keen to run the use cases past the telecomms community in the UK as they are the people who have to face these challenges on a regular basis (and we seem to have an absence of users contributing to this debate for some reason). I don't have a date for this yet, but it's likely to be late October before I can get all the right people together... When would you ideally like comments by and would it be possible to push that date back to accommodate such an effort.

Chris

[This message has been sent by a mobile device]

----- Original Message -----
From: Paul Hoffman [mailto:[email-masked]]
Sent: Saturday, September 08, 2012 05:31 PM
To: IPsecme WG <[email-masked]>
Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements

--Paul Hoffman

****************************************************************************
Communications with GCHQ may be monitored and/or recorded 
for system efficiency and other lawful purposes. Any views or 
opinions expressed in this e-mail do not necessarily reflect GCHQ 
policy.  This email, and any attachments, is intended for the 
attention of the addressee(s) only. Its unauthorised use, 
disclosure, storage or copying is not permitted.  If you are not the
intended recipient, please notify [email-masked].  

This information is exempt from disclosure under the Freedom of 
Information Act 2000 and may be subject to exemption under
other UK information legislation. Refer disclosure requests to 
GCHQ on 01242 221491 ext 30306 (non-secure) or email
[email-masked]

****************************************************************************

The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Sep 2012 17:27:12 -0700

> I'm keen to run the use cases past the telecomms community in the UK as they are the people who have to face these challenges on a regular basis (and we seem to have an absence of users contributin…

Weeks ago, seriously. I am very hesitant to wait for additional requirements comments from people who don't even know about the work without some reasonable expectation that those comments will be useful. I don't want to be harsh, but is there a particular reason that those folks have not participated in the preceding six months?

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Sep 2012 12:22:28 -0400 (EDT)

Hi,

With the TLS compression attack of CRIME hitting the news recently, I
was wondering about this attack against IPsec compression.

While I think the attack is much harder, due to the HMAC, if I
understand it correctly it could still be tried once per user http
request. So if the attacker can trigger the user into connecting
multiple times to some http/https side through the ipsec tunnel, it
could attempt the same one octet replacement.

The Linux *swan implementations do not request compression per default,
but will always do it when the other end requests this, as it was
considered harmless to comply. I want to ensure this train of thought
is still valid, or whether this behaviour should be modified in "no
means no".

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 20 Sep 2012 19:33:14 +0300

Hi Paul,

Can you please clarify why the HMAC mitigates this attack? As far as I 
understand the attack, everything takes place inside the protected 
tunnel, so the HMAC is always correct.

What could mitigate it of course is Traffic Flow Confidentiality (TFC). 
In cases where compression is highly effective, maybe it makes sense to 
sacrifice a few bytes for extra padding.

Thanks,
	Yaron

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Sep 2012 12:41:58 -0400 (EDT)

On Thu, 20 Sep 2012, Yaron Sheffer wrote:

> understand the attack, everything takes place inside the protected tunnel, so 
> the HMAC is always correct.

I thought, but please correct me if I'm wrong here, that with TLS you
can send multiple one-byte-off packets to see the response of the TLS
server. The error or lucky guess will be shown by a different response
on the server. With IPsec, I thought once you sent the one packet, the
HMAC with counter would prevent you from sending more packets for
testing until the client starts another request packet for the attacker
to modify. Though thinking about it again, I guess if the crypto fails
on the packet, it is not received so you can send more packets here as
well.

Paul

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Sep 2012 11:43:15 -0500

> was wondering about this attack against IPsec compression.

Well, in so far as IPsec doesn't have cookies or anything like a
bearer token, it's safe.  However, if you were using IPsec to protect
HTTP web traffic, and if the attacker can find some way to either be
an IPsec peer of your client or get your client to use unsecured HTTP
connections by which the attacker can inject adaptive chosen plaintext
for use in HTTP secured with IPsec, then that would be vulnerable,
yes.  The key is: what's running on top of IPsec?

My thinking is that compression of data needs to be pushed to as high
a layer as possible (i.e., the application layer), where decisions
about what to be compressed (e.g., bulk non-voice/non-real time,
therefore bufferable data) can be left to the part of the system that
can best make them (i.e., the application).

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Thu, 20 Sep 2012 12:48:25 -0400 (EDT)

On Thu, 20 Sep 2012, Nico Williams wrote:

> bearer token, it's safe.

This is not about breaking the IPsec layer, but guessing the session
cookie of an http/https session protected by an IPsec layer.

> However, if you were using IPsec to protect
> yes.

But would they be _more_ vulnerable with compression? If not, then there
is nothing we can do. If compresion does make these attacks easier, I
want to change the default of always allowing it.

> can best make them (i.e., the application).

Yes, compression needs to happen at the plaintext layer, otherwise it
wouldn't compress that much to begin with.

Paul

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Sep 2012 12:13:34 -0500

> want to change the default of always allowing it.

For HTTP (with cookies) the use of compression at *any* lower layer
[that provides session cryptographic protection] creates this
vulnerability.

> wouldn't compress that much to begin with.

I didn't say otherwise.  I said that compression should happen at a
layer (the application layer) that is higher than the transport
protection layer (TLS, ESP, SSH, whatever).  I did not imply that the
alternative is to try to compress at a layer below that where
encryption takes place.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 20 Sep 2012 17:38:19 +0000

With IPSec, compression happens on a per-packet basis; the contents of previous packets do not affect how this packet is compressed in any way.  Hence, there would be a vulnerability only if the attacker can somehow create a single packet that contains both the unknown cookies, as well as his chosen text.  If he can, then likely he could (with sufficient cleverness) figure out a way to exploit it.  However, if his chosen packets contain only what he picked and not the cookies (or whatever else he is interested in), there's no vulnerability.

For TLS, compression is stateful; how this segment is compressed does depend on previous segments; for example, if the text of the segment appears exactly as is in a previous segment, this entire datagram may be replaced with a token that says [Insert X bytes from Y positions from the current stream]; if this entire datagram doesn't appear exactly as is, it'll be replaced with more tokens, and so it won't compress as well.  That makes compression work much better (because it doesn't forget everything at the start of each segment); however, it does introduce the vulnerability that CRIME is based on.

I'm not arguing for/against the idea the compression ought to be done by the application; I'm merely talking about the likelihood of CRIME being an impact of IPSec right now.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Thursday, September 20, 2012 12:43 PM
To: Paul Wouters
Cc: IPsecme WG
Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not?

Nico

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Sep 2012 13:20:42 -0500

> With IPSec, compression happens on a per-packet basis; the contents of previous packets do not affect how this packet is compressed in any way.  Hence, there would be a vulnerability only if the at…

Indeed, and for the BEAST attack being able to manage buffering (via a
"flush" operation, in that case) was critical to the exploit.  And
such buffering functionality existed, indeed.  If the question is "is
IPsec (ESP) immune to this attack" and the answer is (as I think it
is) "it depends on the application" then the fail-safe thing to do is
to disable compression in IPsec (I'm not necessarily recommending that
though).

Nico
--

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 21 Sep 2012 12:15:11 -0700

Hi Tero,

Thanks for the great comments. Your main comments seem to be around
clarifying the terminology and you have very thoughtfully expanded the
definitions. I agree with most of it, just one question in the comments
regarding the same.

We seem to be on the same page here. Please see inline:

> sense, but neither of them might not be good idea in practice.
Perfect. Though we are not solving the problems yet, I guess those are
great inputs for the solution.

> changes to spokes, or hubs further away.
Great inputs will update the definitions in the document based on the
inputs here.

>From our perspective the difference in terminology  (between what you have
said and what the draft says) seems to be the spoke. In our definition a
Spoke is an edge device in the star topology which can be an end-point or a
gateway. Other definitions look good to me.

> themselves. Do we require that spokes also can be behind NATs? What
Yes the aim is ADVPN end points can be behind NAT's. I agree a hub may not
require to be behind NAT, but if two spokes communicate both of them can be
behind NAT's.

> Not really. I still do not understand what you mean by tunnel binding.
The requirement is that in an Enterprise, we may want the branch addresses
to be propagated to the Hub, and run routing protocol over the IPsec
tunnels, even as they change their end point IP addresses. If this is not
clear, would it be possible to expand the question?

> as endpoints do not have any cleartext devices behind them.
Ok, let me look at the complete document for clarity.

> connect directly to that hub, and only use local hub for more local
I am trying to impose the typical enterprise connectivity scenario here -
where the hubs and spokes have permanent connections, while the spoke to
spoke connections come up and go down. I can add your use case too to the
document, but I do not see in cases I know of.

> The intent of the document was to allow for handoff between gateways for
endpoint-gateway-endpoint connectivity. What I was saying was, we can look
at the use case you mention of handing off a connection from
endpoint-gateway-endpoint to endpoint-to-endpoint.

> gateways also includes hubs. I think we really need to define those
Got the point of clarifying the definitions further and will do so.

Thanks,
Vishwas

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Sep 2012 16:14:32 +0300

> great inputs for the solution.

The text in the document claiming that Star topology does not work
when the spokes get dynamic IP address is still wrong. As I explained
in my examples there is nothing in the current protocol specifications
which makes them "not work" or "cannot be configured with". 

> gateway. Other definitions look good to me.

As we are trying to get rid of the rigid star topology (it was listed
in the "Inadequacy of Existing Solutions"), I think we need more
relaxed definition for the spoke. If our star topology is no longer
strict rigid star, but more like dynamic mesh kind of thing, then
talking about what spokes needs to do and what they do not need to do,
gets very confusing. 

> require to be behind NAT, but if two spokes communicate both of them can be

Then we might want to add specific requirements for each class of
devices. 

> clear, would it be possible to expand the question?

As you said it yourself and appended with the rest of the old text: 

	Gateways MUST be able to run routing protocol over the IPsec
	tunnels, even as they change their end point IP addresses.
	This means that applications like Routing using the tunnels
	can work seamlessly without any updates to the higher level
	configuration i.e. OSPF configuraiton.

I did understand that end part of it, but I did not know whether there
was something hidden meaning with the "tunnel binding" part that I did
not get. I mean if there is some other requirements coming from the
"tunnel binding" part then we should explictly say it out here, not
trust that someone who reads the "tunnel binding" knows what those
requirements are. 

> document, but I do not see in cases I know of.

That is fine if we think that spoke-to-hub connections are permanent
and do not change. I think there would be uses for where spoke
realizes that it would be better served by an another hub than the one
which is primarly connected to, and it could connect to another hub in
addition than connecting directly to the all the spokes behind that
hub.

If you feel there is no use case, then we can leave it out. 

> endpoint-gateway-endpoint connectivity.

So you mean that when we have endpoint-gateway-endpoint connection,
and for some reason the gateway wants to hand that connection to so
that connection will be endpoint-another gateway-endpoint?

> What I was saying was, we can look
-- 
[email-masked]