Subject: [IPsec] routing protocols for ADVPN

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Dec 2013 13:41:33 -0500

(thread broken intentionally)

Frederic Detienne (fdetienn) <[email-masked]> wrote:
    >> ...
    >> - No overlay of additional routing protocols is needed.

    > please note that our proposal does not mandate a routing protocol. We
    > also support IKEv2 config exchange and treat the protected subnets as
    > "routes" for the tunnel. 

I have no idea how to implement what you described.
This is the problem: we have asked questions, and we keep getting "oh, yes,
we can do that", but no actual explanation.

I'd rather that you had mandated OSPFv2/3 or someso that I could evaluate the
entire solution.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 6 Dec 2013 21:29:18 +0000

Hi Michael,

Sorry; I must have missed your email or misunderstood your questions. I felt that so far we had received comments asking whether something can be done but very few on how. I have been traveling and missed a bunch of emails. I apologize again if I missed them.

I will split your answer&questions in multiple pieces.

Here is the way we install IKE routes.

When a new peer is discovered or when a spoke connects to a hub for the first time, an IKE exchange begins. Assuming certificate authentication here.

The exchange roughly looks like this

Spoke1     Hub

 SA prop, KEi, Ni    --->
      <--- SA, KEr, Nr
IDi, cert, SIGi, TSi, TSr, cfg_request (SUBNET_v4,…) -->
     <--- IDi, cert, SIGi, TSi, TSr, cfg_reply (SUBNET_v4=192.168.0.0/16,…)
cfg_set (SUBNET_v4=192.168.10.0/24) --->
     <--- cfg_ack (SUBNET_v4)

On the Hub, a dynamic tunnel interface is created on the hub due to authentication success. This interface is protected by the IPsec SA negotiated here. Assuming this interface gets named Tu1.

On the spoke, we can assume the interface preliminary existed since the spoke statically knows the hub. Assuming this interface gets named Tu0. This interface is also protected by the IPsec SA's.

Notice the SA's have Traffic Selectors protecting GRE traffic from hub to spoke physical addresses in transport mode (and vice versa).

On spoke, IKE installs a prefix in the RIB such that
192.168.0.0 / 16 --> Tu0

On the hub, IKE installs a prefix in the RIB such tat
192.168.10.0 / 24 --> Tu1

I.e. IKE forces the traffic negotiated in the IKE exchange

I will add a section to this effect in the draft.

best regards,

	fred

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 6 Dec 2013 21:37:39 +0000

> I'd rather that you had mandated OSPFv2/3 or someso that I could evaluate the

The point is that we can't mandate that. Each of those protocols have different properties and are better suited in various environments.

Now to be honest, simple protocols such as BGP work best for scale but many customers choose their protocol based on what they know best or feel is easier to configure.

Now if we impose, say BGP, the many will scream in despair.

OTOH, without routing protocol however, those who need 100,000 prefixes to be routed across their VPN will not easily be served by a pure IKE/IPsec spec.

We still have not clarified in the other drafts how to tackle spokes that required hauling several thousand prefixes.

thanks,

	fred

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Dec 2013 13:08:27 -0500

> The point is that we can't mandate that. Each of those protocols have
    > different properties and are better suited in various environments. 

So, I should implement all of them the smartphone version?

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

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Sun, 8 Dec 2013 18:57:19 +0000

> On 08 Dec 2013, at 12:08, "Michael Richardson" <[email-masked]> wrote:
> 
> 

Not at all! This is exactly why the draft does not mandate any routing protocol.

The smartphone version can be happily limited to CFG exchange which is part of IKE. No routing protocol necessary.

OTOH, a linux device acting as a router may want to run a routing protocol over the tunnels if it has to protect a large network (dozens of prefixes or more). At this point, what goes into the tunnels is controlled by the routing protocol and DMVPN is simply there to discover the end points, offer secure tunneling or apply additional rules implementing a PAD if sorts (packet filters, firewall rules, unicast reverse path checks, ...).

Notice the mechanism allows multicast without adding anything to the specification for instance.

Whether the branch is a smartphone joining via IGMP or a router relying on PIM, whether SSM or Sparse or anything else, IKE is free of that.

Something that will require further specification in a pure IPsec, selector-based spec.

Thanks,

  Fred

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Dec 2013 16:07:30 -0500

> Not at all! This is exactly why the draft does not mandate any routing

Again, as I said.  
This protocl is infinitely flexible, which means that there is no interoperability. 

    > The smartphone version can be happily limited to CFG exchange which is
    > part of IKE. No routing protocol necessary. 

So, how does my smartphone tell your smartphone where it is so that the RTP
traffic can flow directly, if neither one of us has a routing protocol, or if
we have different onces?

    > Whether the branch is a smartphone joining via IGMP or a router relying
    > on PIM, whether SSM or Sparse or anything else, IKE is free of that. 

I understand that you see modifications of IKE as a challenge.
We see modification of anything else as a challenge; and a security threat.

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Sun, 8 Dec 2013 23:00:05 +0000

> This protocl is infinitely flexible, which means that there is no interoperability. 

So like…  everyone implements all the cypher suites in IKE so IKE does not work ? or  BGP is inflexible and/or there is no interoperability ? Or the Internet uses a single protocol ?

Now if it helps clarifying our position:

- no routing protocol is mandatory. It is up to the customer to specify the adjunction of a routing protocol in their RFP (should they need a routing protocol)
- IKE CFG Exchange MUST be supported as it is defined in IKEv2 and is not specified as optional.

> traffic can flow directly, if neither one of us has a routing protocol, or if

Because there is no reliance AT ALL on the routing protocol (or IKE CFG policies) between spokes. Between spokes, the only protocols in play are NHRP and IPsec/IKE as given in draft-detienne.

It is NHRP that installs that discovers the shortcut path and the shortcut policy is installed solely based on that protocol. The routing protocol(s) (or IKEv2 CFG subnets) is/are irrelevant.

> I understand that you see modifications of IKE as a challenge.

You are missing the point. We would rather not modify something for the sake of it (I do not think any other author would do that). We are however absolutely open to discussing a revamp of the encapsulation of our proposal on the ground of a serious debate.

I am politely challenging that draft-sathyanarayan-ipsecme-advpn is called simple as it misses on many basic things. By the time missing parts are completed, it will be a monster or it will be full of holes and/or quirks.

I am just raising to your and the group's attention that draft-detienne covers both the software client and the complex gateway-gateway a finite manner.

Can someone PLEASE explain me how draft-sathyanarayan covers multicast, scalability (more than 256 networks per branch) and dynamic network changes behind the spoke ? I will have other questions after that.

> We see modification of anything else as a challenge; and a security threat.

That is another strange point… what "else" does draft-detienne "modify" ? Can you elaborate on that ?

thanks,

	fred

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Dec 2013 17:04:44 -0800

<hat on>

> Now if it helps clarifying our position:

Stop this, please. It is rude to hijack a thread that is specifically for non-authors. If you want to clarify a position, simply update the draft.

To everyone else who is not an author of a draft: please see the first message in the thread <http://www.ietf.org/mail-archive/web/ipsec/current/msg08861.html> and consider voicing your opinion, hopefully without debate from document authors.

--Paul Hoffman

---

From: "Rajeshwar Singh Jenwar (rsj)" <[email-masked]>
Date: Mon, 9 Dec 2013 08:24:28 +0000

Hi Paul/Community,

Discussion  on a draft a good  thing for whole community and it benefit the design rationale for future reference.
So,  discussion on a draft can still go on "in a separate thread" .
While people are doing selection on another thread.

Most of time, discussion get started with open ended question, revising the draft may not be equally beneficial.

Kind Regards,
Raj

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Monday, December 09, 2013 6:35 AM
To: Frederic Detienne (fdetienn)
Cc: <[email-masked]>
Subject: Re: [IPsec] routing protocols for ADVPN

<hat on>

--Paul Hoffman
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Dec 2013 08:55:20 -0500

> So like…  everyone implements all the cypher suites in IKE so IKE does
    > not work ? or  BGP is inflexible and/or there is no interoperability ?
    > Or the Internet uses a single protocol ?

We have specified a number of mandatory to implement cipher protocols.
IKE *itself* is mandatory if you are doing automatic keying.  IKE performs
the operation of getting agreement on various things.  This is how the
Internet works.

    > - no routing protocol is mandatory. It is up to the customer to specify
    > the adjunction of a routing protocol in their RFP (should they need a
    > routing protocol)

RFP?   I speak regularly about the need for specific profiles or
applicability statements so that customers can be very clear in their RFPs.
You have just turned over the entire test process to the customer: we might
as well go home.

    > not specified as optional.

I understand that this is going to specify the IP of the virtual interface on
which the routing is going to occur.   I don't know how it is going to
automatically tune any of the important things, including the way the routing
policy is going to be influenced.

I also think that you've completely missed how the software is going to get
deployed onto mobile devices: it won't be Cisco or Juniper providing some
software that installs on an Android or iOS or WinPhone device, it's going to
be Google/Samsung/Motorola/HTC and Apple and Microsoft.

The customer's RFP will be limited by what they can get from those companies,
and if you don't specify it well enough, please expect to make code changes
to your core routing platforms to accomodate interoperability issues there.

    > Because there is no reliance AT ALL on the routing protocol (or IKE CFG
    > policies) between spokes. Between spokes, the only protocols in play
    > are NHRP and IPsec/IKE as given in draft-detienne.

    > It is NHRP that installs that discovers the shortcut path and the
    > shortcut policy is installed solely based on that protocol. The routing
    > protocol(s) (or IKEv2 CFG subnets) is/are irrelevant.

Ah. I see.
I don't need a routing protocol, I just need NHRP on the smartphone.
Thank you for this clarification.

    > Can someone PLEASE explain me how draft-sathyanarayan covers multicast,
    > scalability (more than 256 networks per branch) and dynamic network
    > changes behind the spoke ? I will have other questions after that.

multicast is a good question.
I would like to understand why 256 networks per branch is an issue beyond the
problem of IPv4 RFC1918 address space.

    > ? Can you elaborate on that ?

Routing protocols have been deseperately hard to secure.  Many organizations
that wish to deploy ADVPN mechanisms want to do so across multiple
administrative and jurisdictional domains: a group key based mechanism common
in OSPF isn't going to pass the security thread analysis.

We will need mechanisms such as SIDR (RPKI) achieve the same level of
security with a layered approach as we have with star-topology based IKE.

And I'm still unclear which routing protocol lets routes for RTP traffic be
redirected, but not port-80 (or port-139!) traffic.  So there will have to be
extensions there too.

---

From: "Manish Kumar (manishkr)" <[email-masked]>
Date: Mon, 9 Dec 2013 16:00:36 +0000

Hi Paul,

I'm assuming it's OK to go ahead with discussion on this thread (different
from the selection thread). I believe it's still valuable to have the
discussion continue while the protocol selection continues.

Hi Mark,

Inline [Manish].

Thanks,

On 09/12/13 7:25 PM, "Michael Richardson" <[email-masked]> wrote:

>    > So likeŠ  everyone implements all the cypher suites in IKE so IKE
>does
[Manish]: The packet forwarding on a node relies on the routes present in
the routing table irrespective of how it's learnt; the relevant routing
information between two IPSec peers could, for example, even be static on
one end and dynamically learnt on another. There is no need for a
'mandatory' routing protocol because we don¹t need one. Different parts of
the networks might be running different routing protocols or even learn
routes from out of band means (like static configuration, etc) and that's
just fine, I don't see a need for limiting that.
>You have just turned over the entire test process to the customer: we
[Manish]: Different routing protocols are suitable for different use
cases, otherwise we shouldn't have seen these many coming up and widely
adopted. Depending on their environment and the used case, one might be
more suitable that the other; there's no need to force.
>
>    > - IKE CFG Exchange MUST be supported as it is defined in IKEv2 and
>is
>    > not specified as optional.
>
[Manish]: And possibly subnets behind (for a gateway). I'm not sure if I
followed the second part here, but If I did, this depends on a number of
other things like longer match better metric, etc.
>be Google/Samsung/Motorola/HTC and Apple and Microsoft.
[Manish]: I understand it could be enticing to implement more and more
functionalities(and layers) into a single protocol for light devices
despite there being protocols doing that pretty well already. This might
have its weight but if we had been doing this all these years we wouldn't
have seen the Internet grow to where it's today. Also, as someone pointed
out earlier, these devices off late are already much more powerful than
some of the low end routers.
>Thank you for this clarification.
[Manish]: Well, it's lighter than IKE itself. Further, If you need a
certain functionality, you still need to do it regardless of which
protocol it's implemented in. There could be additional overhead but this
you always have whenever a new protocol is implemented. Keeping it modular
keeps it flexible and avoids the need to reinvent the wheel of having to
build similar functionality in many protocols.
>problem of IPv4 RFC1918 address space.
[Manish]: More than the address space, I don't see how it caters to
dynamic network change unless we build the equivalent of a dynamic routing
protocol within IKE.
>    > That is another strange pointŠ what "else" does draft-detienne
>"modify"
>    > ? Can you elaborate on that ?
>
[Manish]: The routing protocol on the overlay network that is in play here
generally (unless you explicitly differentiate it based on a policy) gets
the same treatment as the data packets. So, the routing exchanges go over
the same tunnel as the data packets; you don't need he mechanisms
typically used in a non-secure environment. Additionally, as mentioned
earlier, the semantic of the route distribution at the administrative
boundaries is total governed by the policies of the involved
administrative domains.
>redirected, but not port-80 (or port-139!) traffic.  So there will have
[Manish]: The point here is that it's more a general path selection
problem better handled in routing than the 'kind of security treatment' a
class of traffic receives. Ask yourself the question, given the topology
and your end goal, wouldn't you have the same policy with or without
IPSec. In the specific example of the need to monitor a class of traffic
on the hub while allowing other directly through, given the same topology,
you would have likely wanted the same policy even if all this was not
IPSec protected.