Subject: [karp] [Gregory Lebovitz] Re: Preliminary Findings on in-band vs out-of-band for KARP

From: Sam Hartman <[email-masked]>
Date: Thu, 29 Jul 2010 03:44:01 -0400

Hi.  I'd be happy to write this up as a draft if useful.

Subject: Re: Preliminary Findings on in-band vs out-of-band for KARP
From: Gregory Lebovitz <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Dacheng Zhang <[email-masked]>, Xu Chen <[email-masked]>
Date: Wed, 28 Jul 2010 23:50:18 -0700

Do you want to send this analysis and thinking to the list?

On Tue, May 11, 2010 at 5:34 PM, Sam Hartman <[email-masked]
> wrote:

> [Gregory, Apologies for the redundant tone of this.  I wanted to write
> up our discussions for the folks I'm working with (copied) and
> eventually for a message to the WG.  So, I include some background at
> the top which you know.]
>
>
> Gregory and I had a call a couple of weeks ago in which we explored two
> approaches for key management.
>
> The first, called out-of-band key management is what KARP is chartered
> to do.  The idea is that there is some key management protocol
> independent of the routing protocols.  It presumably runs on its own
> port, uses its own transport (or reuses TCP/UDP/DCCP/take your pick).
> When a routing protocol needs a key, it contacts the local instance of
> the key management protocol and requests a key.  The local instance may
> be able to generate the key based on a preshared key or based off
> previous interactions.  Alternatively it may need to contact a remote
> key manager.  Eventually, assuming things work, the peers involved end
> up with a key that is delivered to the routing protocol.  This is
> attractive because it may allow the key management to be decoupled from
> the routing protocol and will avoid changing the state machine of the
> routing protocol.
>
> At the WG meeting, several security folks including myself raised
> concerns about this approach and favored in-band key management.  In
> in-band key management, the key management messages are carried within
> the routing protocol.  The potential advantage is that by being tightly
> tied to the routing protocol, you can simplify both the implementation
> and especially standardization of the key management options.  In this
> approach it seems likely that you would want to reuse blocks of code
> between routing protocols.  However there would be more flexibility in
> how these blocks of code were composed and there would not be as much of
> a requirement for strictly isolated interfaces.  One consequence of this
> might be that several classes of interfaces that need to be standardized
> for interoperability in the out-of-band approach are local matters in
> the in-band approach.
>
> My guess was that routing daemons would need to maintain more state for
> the out-of-band key management approach and that the goal of using
> out-of-band key management to simplify implementations would not be
> achieved.
>
> We agreed that guess work was not good enough and that I should go down
> the path of trying to understand what state was required in both
> approaches  and see what the implementation complexity was like.
>
> My preliminary conclusion is that the difference between the out-of-band
> and in-band approaches  is not as much as I had anticipated.
> If this conclusion holds, it seems that the political advantages of the
> out-of-band approach will  justify its use here.
>
> So, what state did I identify that needs to be involved?
>
> In both approaches, the following need to be maintained as part of the
> key management:
>
> * What mechanism (preshared keys, public keys, EAP, whatever, whatever)
> is used?
> * Specific to that approach, what credentials are used
> * An authorization strategy specific to the approach.  For example peer
> matching rules for certificates, something simple for preshared keys (if
> the key matches, we trust the other guy)
> * Within the authorization strategy a set of policies--for example, the
> specific acceptable peers for a given policy.
>
> The following state needs to involve the routing protocol co,de in both
> approaches:
> * What interfaces/areas/peers/paths are protected
> ** Credential used for this protection
> ** Authorization policy used
> ** Integrity key, algorithm
>
> Let's take a look at why these need to be routing protocol specific.
> Each routing protocol has a different idea of what needs to be
> protected.  For example, for OSPF, do I want to configure security on a
> per-area basis, on a per-interface basis, or what?  How do I handle
> virtual links?  For BGP, I presumably want to configure security on a
> per-peer basis.
> The level of detail about what the granularity of security configuration
> is  is protocol specific.
>
> Also, since the actual integrity checks belong inside the protocol in
> our architecture,  then the integrity keys need to belong there.
>
> Now, the per-interface configuration can point to a security policy
> describing what credential to use and describing the parameters specific
> to that credential.
>
> Authorization can again be a pointer to a policy, but the pointer needs
> to live in the routing protocol because the granularity is on the
> interface/area/peer/whatever level.
>
> There are actually two approaches we could take for authorization.  The
> first is what I've done above.  Given security credentials we make a
> decision about whether the credential is appropriate in a given context.
>
> An alternate approach is in some sense better but more complicated.
> There we map security credentials to protocol specific names.  That is,
> we somehow have a rule for finding out that cert x belongs to the OSPF
> router with router ID 10.0.0.2.  Then, we specify the authorizations in
> terms of the objects managed by the specific routing protocol.  So, we
> specify a set of OSPF routers that are allowed in a specific area.  This
> approach involves routing-protocol-specific names making their way
> through a lot more of the system.  That's why I prefer the first
> approach.
>
> We still need to consider the implications of auditing and
> router-protocol-specific names.  Somehow an operator needs to be able to
> know that the IS-IS router claiming a particular MAC address is using a
> particular credential.  This is the sort of thing you need in a security
> log especially when something potentially bad has happened.  It's
> important to stress that it's not good enough to know the identifier
> presented during the key management exchange: you need to link that
> identifier all the way to the appropriate identifier used in the routing
> protocol messages.  At some level this means that either routing
> protocols are going to need to know about names used in the key
> management protocol or that the key management protocol is going to need
> to know about names used in the routing protocol.  Remember that not all
> routing protocols use the same names.  A lot of them use IP addresses;
> some of those use IP addresses corresponding to the interface of a
> link.  Others use an IP address corresponding to a loopback interface.
> However things like IS-IS also use MAC addresses.
>
> On top of this basic state, what's required in the routing protocol to
> make the out-of-band approach work?
> * State machine changes for new requests
>
> You're trying to send a message or validate a message.  You ask for  a
> key from your key management protocol; one is not available.  We need to
> examine the impact of this  on router protocol state machines.  How does
> it impact convergence, retransmission times, etc.
>
> * State machine change for in-progress key-management.
>
> You try to send a message to someone  but you don't have a key yet.
> You're already waiting for one from the key management engine.  This can
> be folded into the above  although second and subsequent messages may
> have more of an impact .  Also, this serves as a reminder that things
> like hello times need to be tuned  to work with the expected times of
> the out-of-band key management.
>
> * Where do you send group key requests.
>
> I've been thinking in particular about OSPF this week.  When you're
> sending a unicast message for an IP-based routing protocol, it's
> reasonably easy to assume that the routing protocol could request a key
> in such a way that the key management engine knew which peer to interact
> with.  That doesn't seem true for multicast messages or for things like
> IS-IS or RSVP.  A significant advantage of a routing protocol on a
> broadcast link is that you don't need to statically configure all the
> neighbors.  However this means that only the routing protocol is in a
> good position to know who the neighbors are.  Somehow that information
> needs to get to the key management protocol.  Also, bootstrapping seems
> to involve a fairly complex interaction.  Initially the routing protocol
> knows who possible neighbors who may have a group key are, although
> before the group key is known, this cannot be integrity protected.
> After the group key is learned, the impact of non-integrity-protected
> information needs to be considered.
>
> One response to this would be to claim that the out-of-band key
> management protocol should run its own mechanism for discovering
> neighbors and should not use the routing protocol's concept of potential
> neighbors.  This is a possibility.  It has several drawbacks.  First, it
> seems likely that things could be operationally fragile  if the routing
> protocol's idea of neighbors can get out of sync with the key management
> protocol.  Second, it may be harder to communicate the scope of a group
> across which the key management protocol should discover neighbors; the
> naming issue surfaces again.
>
> * Session management information.
>
> At the integrity key level, some sort of key ID  is needed.  At the key
> management level, it's desirable for both sides to agree on the scope of
> the key being created--for example which OSPF interface do we want a key
> for?  This basically involves the routing protocol being able to give
> the key management system the name of a key it is requesting and for
> that to be consistent across the network.
>
> * Life time information: when does a key start and how long is it valid
>  for?
>
> Now, let's take a look at what's required for in-band key management.
>
> * Session identification is required to know what integrity key to use.
>  This can often be tied to a key management context in the in-band
>  case.
> If it cannot, then that state is required as well.
>
> * The state machine needs to be changed.  Unlike in the out-of-band case
>  where the state machine needs to insert delays while key management
>  happens, the state machine needs to be changed to permit sending of
>  key management messages.
>
> * Part of the where do you get group keys problem is shared with
>  out-of-band.  In the in-band case, knowing who to talk to is
>  relatively easy.  However, you still must deal with what happens
>  to the protocol's idea of trust before the group key is obtained.
>
> There actually isn't much that is different in terms of state maintained
> in the two approaches.  I actually guess that's not entirely surprising
> since they're accomplishing the same goal.
>
> However there is another interesting axis to consider.  To what extent
> do the specific details differ between routing protocols.  A number of
> cases have been identified::
>
> * What interfaces/peers to interact with
> * How routing protocols name peers
> * How keys are named
> * How multicast key managers are found
> * State machine interactions while waiting for/doing key management
>
> These are areas where either the key management layer will need to know
> about the routing protocol, or where special considerations will need to
> be taken to avoid that.
> In general, the in-band approach will do a better job of permitting this
> sort of cross-layer interaction.  Handling these issues in the
> out-of-band approach will tend to require more abstraction, which
> directly translates to standardization complexity and tends to translate
> to code complexity.
>
> I think the next step is to focus on the issues where things differ
> between routing protocols and see if we can come up with solutions to
> isolate one layer from another.
>
> --Sam
>
>

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks