Subject: Re: [IPsec] AD VPN: discussion kick off

From: Michael Richardson <[email-masked]>
Date: Fri, 1 Nov 2013 16:22:59 -0400 (EDT)

: signature: ~/.signature.ietf
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 01 Nov 2013 16:22:58 -0400
Message-ID: <[email-masked]>
Sender: [email-masked]

--=-=-=
Content-Transfer-Encoding: quoted-printable

I have read all three proposals, although I missed the Q&A in Berlin.
I am looking forward to further Q&A in Berlin.

When I read the NBMA protocol (DMVPN, I think) version what I saw was a ver=
y brilliant hack=20=20
that managed to take two code bases (IPsec and ATM) that were likely alread=
y present
in that vendor's firmware and connect them.  Likely, it took only a few wee=
ks of
brilliant hacking, and it was ready for customer use.

I find that this solution for anyone else involves the most amount of new c=
ode,
and I think it will the most difficult to support on various mobile and lap=
top=20
platforms as it requires new encapsulation modes.

draft-mao-ipsecme is architecturally the closest to me, and I like the ADS =
idea: it
seems that it be implemented without any new kernel code, and I think that =
if we are trying=20
to get remote warrior and branch office RTP traffic to take a more direct r=
oute, then=20
eliminating the need for a more network plumbing, and just doing things in =
IKE is the
right answer.  (%)

I don't like having a new protocol: I want it in IKE.  While it can and sho=
uld
run inside the tunnel, I don't see why adding a new port to my IKE daemon m=
akes
my life easier.=20=20

I do like the way that DMVPN uses probe packets to discover the end points =
of
the shorter routes, and I would look forward to including that mechanism.=
=20=20

I don't like that DMVPN does not let http traffic continue to travel via HQ=
's
virus/trojan/netnanny while RTP takes the shortcut.

(%)- the plumbing might need a way to sample 5-tuple flows to see if there
is traffic that should be shortcut. However, various schemes to put more
specific SPD entries in that cause key requests might accomplish this witho=
ut=20
new kernel code.

Michael Richardson
=2Don the road-

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Nov 2013 15:17:53 -0400

{Sorry about that, the email configuration my tablet had a \n in a header
that did not belong}

When I read the NBMA protocol (DMVPN, I think) version what I saw was a very
brilliant hack that managed to take two code bases (IPsec and ATM) that were
likely already present in that vendor's firmware and connect them.  Likely,
it took only a few weeks of brilliant hacking, and it was ready for customer use.

I find that this solution for anyone else involves the most amount of new code,
and I think it will the most difficult to support on various mobile and laptop 
platforms as it requires new encapsulation modes.

draft-mao-ipsecme is architecturally the closest to me, and I like the ADS
idea: it seems that it be implemented without any new kernel code, and I
think that if we are trying  to get remote warrior and branch office RTP
traffic to take a more direct route, then  eliminating the need for a more
network plumbing, and just doing things in IKE is the right answer.  (%)

I don't like having a new protocol: I want it in IKE.  While it can and
should run inside the tunnel, I don't see why adding a new port to my IKE
daemon makes my life easier.  

I *do* like the way that DMVPN uses probe packets to discover the end points of 
the shorter routes, and I would look forward to including that mechanism
somehow.  I don't know how to do that without hacks to the data plane, which
I'd like to avoid.  I can imagine some ways to do this with a traceroute
process, but it seems kludgy and brittle. (really, that's still dataplane,
but it's using an existing mechanism)

I don't like that DMVPN does not let http traffic continue to travel via HQ's
virus/trojan/netnanny while RTP takes the shortcut.

(%)- the plumbing might need a way to sample 5-tuple flows to see if there
is traffic that should be shortcut. However, various schemes to put more
specific SPD entries in that cause key requests might accomplish this without  
new kernel code.

--
Michael Richardson
-on the road-

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: "Manish Kumar (manishkr)" <[email-masked]>
Date: Tue, 5 Nov 2013 21:08:27 +0000

Michael,

"I don't like that DMVPN does not let http traffic continue to travel via
HQ's
virus/trojan/netnanny while RTP takes the shortcut."

While I do appreciate that the following could represent a valid used
case, it would be inaccurate to say DMVPN doesn't allow this. It does
allow but not using the IPSec tools; the protocol programming the
forwarding layer(could be policy based) controls what goes via the hub as
opposed to what goes on the shortcut tunnel. Also, I would see this more
as a path selection problem more than 'the kind of security treatment a
certain class of traffic needs' - it's another matter that different paths
provide different security services/treatment. Since, the network topology
information and hence the path that a class of traffic may take is not
privy to IKE/IPSec, it's only appropriate that a protocol aware about this
takes this call. This is the reason I don't concur with your other comment
about doing this in IKE.

Cheers,
Manish

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Nov 2013 16:45:37 -0500 (EST)

> takes this call. This is the reason I don't concur with your other comment

Couldn't that policy be exposed in IKE using traffic selectors for port
80 or 443? In all of the three proposed solutions?

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Nov 2013 23:50:15 +0000

> 80 or 443? In all of the three proposed solutions?

Not really. In DMVPN the only selectors are {Gw-IP, GW-IP, Proto=47}, because everything goes through a GRE tunnel. 

In draft-mao it's IPsec tunnels, but they still use universal selectors and selecting traffic through a routing protocol. 

In both cases you can get what you're looking for if you have routing based on port. It's only in draft-sathyanarayan that you can do that with IPsec traffic selectors.