Re: [IPsec] routing protocols for ADVPN

[Michael Richardson <[e-mail]>]

Frederic Detienne (fdetienn) <[e-mail]> wrote:
    >> Again, as I said.
    >> 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 ?

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.

    > 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)

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.

    > - IKE CFG Exchange MUST be supported as it is defined in IKEv2 and is
    > 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.

    >>> 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?

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

    >> 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 ?

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.

--
Michael Richardson <[e-mail]>, Sandelman Software Works