Subject: [karp] Please take a look at draft-hartman-karp-ops-model-00.txt

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Jul 2010 17:06:36 -0400

Folks, we'de like to ask you to take a look at
draft-hartman-karp-ops-model-00. This is our initial thoughts on ops and
management models for KARP.

At this point it's more issues to consider and things to be thinking
about than it is solutions.

One thing we definitely need to do is expand the references section and
cite some previous thoughts in this space, including some of the O&M
discussions in the framework document.  Long term, I think some of those
discussions could move into a WG document like this rather than being
directly in the framework.

---

From: Bill Atwood <[email-masked]>
Date: Wed, 14 Jul 2010 15:33:57 -0400

Sam,

I have read karp ops model document, and learned some interesting
things, in addition to having some of my already-formed opinions
re-enforced.  Thank you for this work.

In the discussion of key configuration (Section 3), you present the
cases of per-area and per-interface.  I believe that you need to
consider per-peer as well.

When multicast is used from a 'speaker' to its neighbors, and assuming
that a source address is a permitted selector for multicast security
associations (as defined in the most recent IPsec specifications), then
a router can distinguish packets from each of its peers (neighbors), and
utilize a different Security Association for each one.  Clearly this
will require automated key management, but it will also give the
smallest vulnerability if a key is compromised.

  Bill

On 7/5/2010 5:06 PM, Sam Hartman wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Gregory Lebovitz <[email-masked]>
Date: Sun, 25 Jul 2010 05:09:01 -0700

Hey Sam and Dacheng,

Here is a review of the ops-model document. I look forward to ongoing
discussion about it.

General Comments

GML> Sam & Dacheng, what do you want to do with this text? Do you want this
to go into the Design-guide document? Do you want it to stand alone as it's
own RFC? I was thinking that a lot of it, as currently written, feels like
design-guidance to the design teams. Your thoughts?

3. -

   Another
   approach would be to notice that it is common to use the same
   authentication information across an area and configure the keys as a
   property of the area.  Doing so makes configuration easier in a
   common case at the expense of generality.

GML> OSPF also has different security properties in that OSPF may commonly
run intra-domain, behind a security permiter, where the attach volume is
greatly reduced compared to something sitting on the Internet.

   If keys are configured
   per-area then the system may not support configuring different keys
   for links in the same area.

 GML> Agree. Need to make sure that implementations do not prohibit per-link
keys vs per area keys.

   Another option would be to have some
   sort of inheritance where default configurations are made per-area
   unless overridden per-interface.

 GML> that would work. This is definitely a vendor implementation option.
However, it's one that would assist interop greatly if we all agreed do
enforce the same default behavior.

   An implementation could directly store the information about a given
   key in its configuration scope.  That is, if the key was configured
   on an interface, then the parameters of that key would be stored with
   the interface.

GML > This is a vendor implementation detail, about how the keys and
security association parameters will be stored and associated. However, one
must consider the use of KARP for protocols not necessarily tied to specific
interfaces. For example, BGP PeerA may be able to reach PeerB via multiple
paths, physical ports, or L3 routing interfaces (e.g. it might have 2 or 3
OSPF interfaces that all can reach PeerB). I think the definition of when I
want to use keys has more to do with peers than with interfaces or links,
specifically. Alternatively, some abstract key object could be associated
with multiple interfaces.  This approach might be more complicated but would
make it easier to update a key if the same key were used for multiple
protocols or in multiple configuration scopes.

GML > another idea is per-neighbor keys, i.e. anyone that wants to talk to
me uses key213, and this security association.

4. -
   Several methods for authentication have been proposed for KARP.  The
   simplest is preshared keys used directly as traffic keys.  In this
   mode, the traffic integrity keys are directly configured.  This is
   the mode supported by today's routing protocols.

   Preshared keys could also be used by an automated key management
   protocol.

 GML> There is an in-between option, and it's the one we used in TCP-AO: a
PSK is used as in input on both sides to create the actual traffic keys.
This is helpful because then other things can be mixed in with the PSK as
needed to achieve additional security requirements, like connection specific
information for inter-connection replay protection, and direction-specific
information so that direction-specific traffic keys can be derived from one
(confirgured) PSK.

   In this mode, preshared keys would be used for
   authentication.  However traffic keys would be generated by some key
   agreement mechanism or transported in a key encryption key derived
   from the preshared key.  This mode may provide better replay
   protection.  Also, in the absence of active attackers, key agreement
   strategies such as Diffie-Hellman can be used to produce high-quality
   traffic keys even from relatively weak preshared keys.

   Note that self-signed certificates are a
   common way of communicating public-keys in this style of
   authentication.

GML > I'm glad to see you promoting, if only by mention, the self-signed
cert mechanism for this. I really like this mechanism. It's a pretty easy
and elegant solution. Validity checking is simple, even for a very large
organization (one with 5k rtr): a flat file list of peer IDs with
fingerprints of associated certs, and this file can be easily deceminated
for local storage or queried over the network. The other advantage of this
mechanism is cost and ease of deployment, as no CA is needed, nor per-key
license fees, etc.

 Certificates signed by a certification authority or some other PKI
 could be used.  The advantage of this approach is that routers may
 not need to be directly updated when peers are added or removed.  The
 disadvantage is that more complexity is required.

GML > I think we can say the same can be made true for the self-signed certs
solution.

4.1 -
 GML> Define "small integer" keyID? What thinking led you to qualify it that
way?

   Typically key IDs
   are names valid only in the scope of one interface or peer.

GML > probably need to be unique per peer, that is, if we want implementers
to be able to use a single key table for KARP.

   Manual preshared keys are often known by a group of peers not just
   one peer.  This is an interesting security property: it is impossible
   to identify the peer sending a message cryptographically; it is only
   possible to identify a group of peers using cryptographic means.

GML > This is true if you use the PSK raw. If, otoh, you use the PSK as a
key derivation key for generation of a traffic key, and use peer specific
information, and/or connection specific information in the traffic key
creation operation, then one can also achieve peer ID validation, as well as
replay protection.

   As
   a consequence, authorization is typically based on knowing the
   preshared key rather than on being a particular peer.  Note that once
   an authorization decision is made, the peer can assert its identity;
   this identity is trusted just as the routing information from the
   peer is trusted.  However, for the process of authorization, it would
   be more complicated to identify peers this way and would not gain a
   security benefit in most deployments.

   Care needs to be taken when symmetric keys are used for multiple
   purposes.  Consider the implications of using the same preshared key
   for two interfaces: it becomes impossible to distinguish a router on
   one interface from a router on another interface.  So, a router that
   is trusted to participate in a routing protocol on one interface
   becomes implicitly trusted for the other interfaces that share the
   key.

 GML> same as above. This issue disappears if you use the PSK to derive a
traffic key.

   For many cases, such as OSPF routers in the same area, there is
   no significant advantage that an attacker could gain from this trust
   within the KARP threat model.  However, other protocols, such as RIP,
   permit routes from a particular interface to be filtered.  For these
   protocols, participation in one interface might be more advantageous
   than another.

GML > For RIP, it usually runs within a specific trust domain, so it may be
less of an issue. BGP is a great example of where your point would be very
applicable, as different BGP interfaces may well each be in a different
trust domain.

   More subtle problems with key separation can appear in protocol
   design...

GML > Good guidance, and nicely explained. Would the PSK as a kdf trick
address this paragraph too?

   As a result, we should use appropriate
   key derivation functions so that different cryptographic keys are
   used even when the same initial input key is used.

 GML> Ahh. There we go. Okay, so we agree that rather than specify the
direct use of PSK's as traffic keys themselves, we ought only specify PSK
used as a kdf to create traffic keys?

4.2 -

GML> after reading the section a few times, I'm wondering if what you are
really discussing is better labeled as asymmetric keys, rather than "public
keys"?

   The Session
   Description Protocol provides a standardized mechanism for naming
   keys (in that case certificates) based on hashes.

 GML> [nit] reader would be served by an inline ref

   KARP SHOULD adopt
   this approach or another approach already standardized within the
   IETF rather than inventing a new mechanism for naming public keys.

GML > Agreed 100%.

   A public key is typically expected to belong to one peer.  As a peer
   generates new keys and retires old keys, its public key may change.
   For this reason, from a management standpoint, peers should be
   thought of as associated with multiple public keys rather than as
   containing a single public key hash as an attribute of the peer
   object.

 GML> Good point. Agreed.

   However management interfaces need to
   be carefully designed to avoid making this extra level of indirection
   complicated for operators.

GML > Agreed. Probably helps to add an example or be more specific by
providing some design tips

4.3 -
   An advantage of this is that it may
   be possible to add a new router with no authentication related
   configuration of the peers of that router.

 GML> do you have a specific example in mind? I'd like to hear more about
how you think this could be accomplished.

  Assuming that potentially self-signed certificates are used by
 routers that wish to use public keys but that do not need a PKI, then
 PKI and the infrastructureless mode of public-key operation described
 in the previous section can work well together.  One router could
 identify its peers based on names and use certificate validation.
 Another router could use hashes of certificates.  This could be very
 useful for border routers between two organizations.  Smaller
 organizations could use public keys and larger organizations could
 use PKI.

GML > Our thinking is aligned exactly here. Based on all my years of IPsec
implementation experience with organizations, I'd say we are likely to get a
LOT more deployment from the self-signed certs and the infrastructureless
mode of public-key operation than we are from genuine PKI. The later will be
used, by by a niche of the market, whereas the former could be deployed
easily, with little infrastructure or config, and therefore has a far
greater chance of broad deployment of KARP.

4.4 -
GML > I think we will see the design and use of central servers before this
is all over in KARP. I continue to feel, as you penned, that we'll need them
for mcast'ing protos. I suggest we focus on the simpler mechanisms for
leveraging asymmetric keys, i.e. self-signed certs plus flat-file whitelists
so that we have some basic tools for implementation and further
testing/experimentation.

7.0 -
GML > when you say "phased upgrade from manual keying to automated key
management" what would those phases look like? Do you mean a network goes
from manual to PSK as kdf, then from PSK-in-kdf to self-signed certs +
flat-file whitelist. Then from there to full PKI? Or are you actually saying
that when moving from one of these to another it must be able to occur
without a halt in adjacency?

GML > If the latter, I'm not sure it's relevant to worry about it, for this
reason: the code doesn't exist to do KARP today. So, in order to get KARP
stuff in place on a network, there will need to be a new software load on
the router. When it reboots to load the new image, the adjacency will break.
Yes, the router, or pair of routers, may have ISSU, but even then, there
will some cut-over. The operators already have methods for rolling out such
upgrades, so I'm not sure we have to stress over it too much at this
moment.

That's it. See you soon,
Gregory

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 28 Jul 2010 09:06:37 -0400

Hi.  I will respond in detail in about two weeks and incorporate most of
your suggestions.

however I think there's one area of disagreement it is good to bring up
on the list now so we're prepared to discuss it in the meeting.

You mentioned that several of the choices I discussed about
configuration are vendor specific.

I agree that we could take that position.  However doing so means that
we'll never get good interoperability with management. We would have
some nasty choices when designing a MIB or Netconf schema:

* Support all the possibilities
* Don't manage the objects
* Only get management for some implementations

The first bullet point produces very bad results for managers and
operators.

I've been following the discussions of best practices for managability
and O&M considerations that the O&M area has been working on.  I think
that specifying the sort of details in information model necessary to
make a protocol something we can manage is well within what we'll be
expected to do by the O&M area. I think there is significant value in
starting early and getting as much operator feedback as we can.

---

From: <[email-masked]>
Date: Thu, 29 Jul 2010 10:42:59 +0200

Hi group,

Gregory [Lebovitz], just a quick remark as a routing guy. When you said:

GML > For RIP, it usually runs within a specific trust domain, so it may be less of an issue. BGP is a great example of where your point would be very applicable, as different BGP interfaces may well each be in a different trust domain.

The statement "BGP interface" is inappropriate because to the contrary of other routing protocols, BGP is running over TCP and thus at layer 4. It is thus not attached to any L3 routing-interface. The choice of the egress interface to use so as to establish a session with a peer X is left to the underlying IGP protocol.

Otherwise, I have to say that I share most of your comments (as much as I understand the security stuff).

Kind regards,

 --

Greg

De : [email-masked] [mailto:[email-masked]] De la part de Gregory Lebovitz
Envoyé : dimanche 25 juillet 2010 14:09
À : Sam Hartman; [email-masked]
Cc : [email-masked]
Objet : Re: [karp] Please take a look at draft-hartman-karp-ops-model-00.txt

Hey Sam and Dacheng,

Here is a review of the ops-model document. I look forward to ongoing discussion about it.

General Comments

GML> Sam & Dacheng, what do you want to do with this text? Do you want this to go into the Design-guide document? Do you want it to stand alone as it's own RFC? I was thinking that a lot of it, as currently written, feels like design-guidance to the design teams. Your thoughts?

3. - 

   Another

GML> OSPF also has different security properties in that OSPF may commonly run intra-domain, behind a security permiter, where the attach volume is greatly reduced compared to something sitting on the Internet.

   If keys are configured

 GML> Agree. Need to make sure that implementations do not prohibit per-link keys vs per area keys.

 GML> that would work. This is definitely a vendor implementation option. However, it's one that would assist interop greatly if we all agreed do enforce the same default behavior.

   the interface.

GML > This is a vendor implementation detail, about how the keys and security association parameters will be stored and associated. However, one must consider the use of KARP for protocols not necessarily tied to specific interfaces. For example, BGP PeerA may be able to reach PeerB via multiple paths, physical ports, or L3 routing interfaces (e.g. it might have 2 or 3 OSPF interfaces that all can reach PeerB). I think the definition of when I want to use keys has more to do with peers than with interfaces or links, specifically. Alternatively, some abstract key object could be associated with multiple interfaces.  This approach might be more complicated but would make it easier to update a key if the same key were used for multiple protocols or in multiple configuration scopes.

GML > another idea is per-neighbor keys, i.e. anyone that wants to talk to me uses key213, and this security association.

4. -

   protocol.  

 GML> There is an in-between option, and it's the one we used in TCP-AO: a PSK is used as in input on both sides to create the actual traffic keys. This is helpful because then other things can be mixed in with the PSK as needed to achieve additional security requirements, like connection specific information for inter-connection replay protection, and direction-specific information so that direction-specific traffic keys can be derived from one (confirgured) PSK. 

   authentication.

GML > I'm glad to see you promoting, if only by mention, the self-signed cert mechanism for this. I really like this mechanism. It's a pretty easy and elegant solution. Validity checking is simple, even for a very large organization (one with 5k rtr): a flat file list of peer IDs with fingerprints of associated certs, and this file can be easily deceminated for local storage or queried over the network. The other advantage of this mechanism is cost and ease of deployment, as no CA is needed, nor per-key license fees, etc.

GML > I think we can say the same can be made true for the self-signed certs solution.

4.1 -

 GML> Define "small integer" keyID? What thinking led you to qualify it that way?

   Typically key IDs

GML > probably need to be unique per peer, that is, if we want implementers to be able to use a single key table for KARP.

GML > This is true if you use the PSK raw. If, otoh, you use the PSK as a key derivation key for generation of a traffic key, and use peer specific information, and/or connection specific information in the traffic key creation operation, then one can also achieve peer ID validation, as well as replay protection.

   As

   key.  

 GML> same as above. This issue disappears if you use the PSK to derive a traffic key. 

   than another.

GML > For RIP, it usually runs within a specific trust domain, so it may be less of an issue. BGP is a great example of where your point would be very applicable, as different BGP interfaces may well each be in a different trust domain.

   design...

GML > Good guidance, and nicely explained. Would the PSK as a kdf trick address this paragraph too?

 GML> Ahh. There we go. Okay, so we agree that rather than specify the direct use of PSK's as traffic keys themselves, we ought only specify PSK used as a kdf to create traffic keys?

4.2 -

GML> after reading the section a few times, I'm wondering if what you are really discussing is better labeled as asymmetric keys, rather than "public keys"?

   The Session

   KARP SHOULD adopt

GML > Agreed 100%. 

   object.

 GML> Good point. Agreed.

GML > Agreed. Probably helps to add an example or be more specific by providing some design tips

4.3 - 

 GML> do you have a specific example in mind? I'd like to hear more about how you think this could be accomplished.

           use PKI.

GML > Our thinking is aligned exactly here. Based on all my years of IPsec implementation experience with organizations, I'd say we are likely to get a LOT more deployment from the self-signed certs and the infrastructureless mode of public-key operation than we are from genuine PKI. The later will be used, by by a niche of the market, whereas the former could be deployed easily, with little infrastructure or config, and therefore has a far greater chance of broad deployment of KARP.

4.4 -

GML > I think we will see the design and use of central servers before this is all over in KARP. I continue to feel, as you penned, that we'll need them for mcast'ing protos. I suggest we focus on the simpler mechanisms for leveraging asymmetric keys, i.e. self-signed certs plus flat-file whitelists so that we have some basic tools for implementation and further testing/experimentation.

7.0 -

GML > when you say "phased upgrade from manual keying to automated key management" what would those phases look like? Do you mean a network goes from manual to PSK as kdf, then from PSK-in-kdf to self-signed certs + flat-file whitelist. Then from there to full PKI? Or are you actually saying that when moving from one of these to another it must be able to occur without a halt in adjacency?

GML > If the latter, I'm not sure it's relevant to worry about it, for this reason: the code doesn't exist to do KARP today. So, in order to get KARP stuff in place on a network, there will need to be a new software load on the router. When it reboots to load the new image, the adjacency will break. Yes, the router, or pair of routers, may have ISSU, but even then, there will some cut-over. The operators already have methods for rolling out such upgrades, so I'm not sure we have to stress over it too much at this moment. 

That's it. See you soon,

Gregory

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

---

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 29 Jul 2010 02:05:08 -0700

On 7/29/10 1:42 AM, [email-masked] wrote:
> GML > For RIP, it usually runs within a specific trust domain, so it 
> may be less of an issue. BGP is a great example of where your point 
> would be very applicable, as different BGP interfaces may well each be 
> in a different trust domain.
>
> The statement "BGP interface" is inappropriate because to the contrary 
> of other routing protocols, BGP is running over TCP and thus at layer 
> 4. It is thus not attached to any L3 routing-interface. The choice of 
> the egress interface to use so as to establish a session with a peer X 
> is left to the underlying IGP protocol.
>

Good clarification. Thx.
> *De :* [email-masked] [mailto:[email-masked]] *De la 
> part de* Gregory Lebovitz
> *Envoyé :* dimanche 25 juillet 2010 14:09
> *À :* Sam Hartman; [email-masked]
> *Cc :* [email-masked]
> *Objet :* Re: [karp] Please take a look at 
> draft-hartman-karp-ops-model-00.txt
>
> Hey Sam and Dacheng,
>
> GML> Sam & Dacheng, what do you want to do with this text? Do you want 
> this to go into the Design-guide document? Do you want it to stand 
> alone as it's own RFC? I was thinking that a lot of it, as currently 
> written, feels like design-guidance to the design teams. Your thoughts?
>
> 3. -
>
>    Another
>
> GML> OSPF also has different security properties in that OSPF may 
> commonly run intra-domain, behind a security permiter, where the 
> attach volume is greatly reduced compared to something sitting on the 
> Internet.
>
>    If keys are configured
>
>  GML> that would work. This is definitely a vendor implementation 
> option. However, it's one that would assist interop greatly if we all 
> agreed do enforce the same default behavior.
>
> security association parameters will be stored and associated. 
> However, one must consider the use of KARP for protocols not 
> necessarily tied to specific interfaces. For example, BGP PeerA may be 
> able to reach PeerB via multiple paths, physical ports, or L3 routing 
> interfaces (e.g. it might have 2 or 3 OSPF interfaces that all can 
> reach PeerB). I think the definition of when I want to use keys has 
> more to do with peers than with interfaces or links, specifically. 
> Alternatively, some abstract key object could be associated with 
> multiple interfaces.  This approach might be more complicated but 
> would make it easier to update a key if the same key were used for 
> multiple protocols or in multiple configuration scopes.
>
> GML > another idea is per-neighbor keys, i.e. anyone that wants to 
> talk to me uses key213, and this security association.
>
> 4. -
>
>  GML> There is an in-between option, and it's the one we used in 
> TCP-AO: a PSK is used as in input on both sides to create the actual 
> traffic keys. This is helpful because then other things can be mixed 
> in with the PSK as needed to achieve additional security requirements, 
> like connection specific information for inter-connection replay 
> protection, and direction-specific information so that 
> direction-specific traffic keys can be derived from one (confirgured) 
> PSK.
>
> GML > I'm glad to see you promoting, if only by mention, the 
> self-signed cert mechanism for this. I really like this mechanism. 
> It's a pretty easy and elegant solution. Validity checking is simple, 
> even for a very large organization (one with 5k rtr): a flat file list 
> of peer IDs with fingerprints of associated certs, and this file can 
> be easily deceminated for local storage or queried over the network. 
> The other advantage of this mechanism is cost and ease of deployment, 
> as no CA is needed, nor per-key license fees, etc.
>
> GML > probably need to be unique per peer, that is, if we want 
> implementers to be able to use a single key table for KARP.
>
> GML > This is true if you use the PSK raw. If, otoh, you use the PSK 
> as a key derivation key for generation of a traffic key, and use peer 
> specific information, and/or connection specific information in the 
> traffic key creation operation, then one can also achieve peer ID 
> validation, as well as replay protection.
>
>    As
>
> GML > For RIP, it usually runs within a specific trust domain, so it 
> may be less of an issue. BGP is a great example of where your point 
> would be very applicable, as different BGP interfaces may well each be 
> in a different trust domain.
>
> direct use of PSK's as traffic keys themselves, we ought only specify 
> PSK used as a kdf to create traffic keys?
>
> 4.2 -
>
> GML> after reading the section a few times, I'm wondering if what you 
> are really discussing is better labeled as asymmetric keys, rather 
> than "public keys"?
>
>    The Session
>
>  GML> do you have a specific example in mind? I'd like to hear more 
> about how you think this could be accomplished.
>
> GML > Our thinking is aligned exactly here. Based on all my years of 
> IPsec implementation experience with organizations, I'd say we are 
> likely to get a LOT more deployment from the self-signed certs and the 
> infrastructureless mode of public-key operation than we are from 
> genuine PKI. The later will be used, by by a niche of the market, 
> whereas the former could be deployed easily, with little 
> infrastructure or config, and therefore has a far greater chance of 
> broad deployment of KARP.
>
> 4.4 -
>
> GML > I think we will see the design and use of central servers before 
> this is all over in KARP. I continue to feel, as you penned, that 
> we'll need them for mcast'ing protos. I suggest we focus on the 
> simpler mechanisms for leveraging asymmetric keys, i.e. self-signed 
> certs plus flat-file whitelists so that we have some basic tools for 
> implementation and further testing/experimentation.
>
> 7.0 -
>
> management" what would those phases look like? Do you mean a network 
> goes from manual to PSK as kdf, then from PSK-in-kdf to self-signed 
> certs + flat-file whitelist. Then from there to full PKI? Or are you 
> actually saying that when moving from one of these to another it must 
> be able to occur without a halt in adjacency?
>
> GML > If the latter, I'm not sure it's relevant to worry about it, for 
> this reason: the code doesn't exist to do KARP today. So, in order to 
> get KARP stuff in place on a network, there will need to be a new 
> software load on the router. When it reboots to load the new image, 
> the adjacency will break. Yes, the router, or pair of routers, may 
> have ISSU, but even then, there will some cut-over. The operators 
> already have methods for rolling out such upgrades, so I'm not sure we 
> have to stress over it too much at this moment.
>
> That's it. See you soon,
>
> Gregory
>
> On Mon, Jul 5, 2010 at 2:06 PM, Sam Hartman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
> [email-masked] <mailto:[email-masked]>

-- 
~~~~~~~~~~~~~~
IETF related Email from
Gregory Lebovitz
Juniper Networks