Subject: Re: [karp] Negotiation

From: "Michael Barnes" <[email-masked]>
Date: Thu, 13 Jan 2011 08:42:43 -0800

Hi Sam,

I think there are many ways in which auto negotiation can benefit users and
hope we can work through concerns. Configuration complexity is one reason that
operators don't use sophisticated security, so reducing the configuration
effort should increase deployments.

I suggest that a negotiation mechanism be available but designed so that a
user can control it, or even disable it, through configuration. This way if a
user has some reason to be concerned that the negotiation mechanism won't work
correctly or some issues might be introduced by using such a mechanism, for
example if they are using devices from multiple vendors and don't trust those
devices to be interoperable, then the operator can carefully control the
authentication parameters.

Regards,
Michael

------ Original Message ------
Received: Thu, 13 Jan 2011 08:03:35 AM PST
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: [karp] Negotiation

> At the last meeting, Yinxing Wei asked about our strategy for
> negotiation of cryptographic parameters.
>
> I think this is an important discussion to have.  It's another area
> where I think we may find the security area's default assumptions differ
> from the routing area.
>
> I don't have strong opinions on what the answer is, so perhaps I can try
> and outline both sides as I understand them.  Perhaps this will help get
> things started.
>
> Routing protocols have a fair bit of configuration. For BGP, you need to
> configure peers, AS information and a heck of a lot of policy. Even for
> something like OSPF and IS-IS that try to have a fair bit of automated
> discovery, you need to indicate what area an interface is in. This
> configuration needs to be consistent and synchronized. As a result,
> anyone who has more than a couple of routers has mechanisms for managing
> and updating configuration. Updating what cryptographic algorithms to
> use in a configuration is not that difficult.
>
> One highly undesirable thing in an operational network is when some
> change has unexpected consequences. Here are a couple of situations that
> might help understand why an operator is nervous about negotiation. Two
> peers (A and B) negotiate cryptographic authentication. Before an
> upgrade, everything is working. B supports SHA-1 and SHA-256, but A only
> supports SHA-1. A is upgraded and now supports SHA-256. Unfortunately,
> B's implementation of the routing authentication using SHA-256 is
> buggy. The upgrade causes things to break.  Perhaps you'll argue that's
> not really an unintended consequence: upgrades sometimes expose bugs in
> the systems involved in the upgrade.
>
> However, negotiation can make problems far more hidden. Consider a
> network with routers A, B and C. B and C support SHA-256 and SHA-1, but
> A currently only supports SHA-1. Some protocol with a group key is
> in-use. A is upgraded; as a result the communication between B and C
> happens. This can be the case if C's implementation of SHA-256 does not
> work with B. So, even though neither of the parties directly involved in
> the communication changed software or configuration, the set of
> capabilities on the network changed, which changes what is used.
>
> On the other hand, negotiation in security protocols is useful. Users
> don't tend to update configurations. Also, the more you have to
> configure, the harder it is to get security working. If security
> parameters can be determined automatically without compromising
> security, usability is increased. Negotiation will lead to the gradual
> deployment of better protocols as software is updated. So, negotiation
> is desirable.
>
> Our job is to balance these tradeoffs.
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Jan 2011 12:02:12 -0500

>>>>> "Michael" == Michael Barnes <[email-masked]> writes:

    Michael> I suggest that a negotiation mechanism be available but
    Michael> designed so that a user can control it, or even disable it,
    Michael> through configuration. This way if a user has some reason
    Michael> to be concerned that the negotiation mechanism won't work
    Michael> correctly or some issues might be introduced by using such
    Michael> a mechanism, for example if they are using devices from
    Michael> multiple vendors and don't trust those devices to be
    Michael> interoperable, then the operator can carefully control the
    Michael> authentication parameters.

I think that the best way to do this if desired to simply permit a user
to constrain the set of allowed negotiation results down to one option.
That removes the testing complexity of sometimes having negotiation and
sometimes not.

If we can get consensus behind this I'm fine.  I know that Gregory and a
couple of others have expressed concerns about this approach.

---

From: [email-masked]
Date: Wed, 19 Jan 2011 16:26:32 +0800

Hi Michael,

I do agree with you.

Cheers,
Ellen (Xiaoping Liang)

"Michael Barnes" <[email-masked]> 
发件人:  [email-masked]
2011-01-14 00:42

收件人
Sam Hartman <[email-masked]>
抄送
[email-masked]
主题
Re: [karp] Negotiation

Hi Sam,

I think there are many ways in which auto negotiation can benefit users 
and
hope we can work through concerns. Configuration complexity is one reason 
that
operators don't use sophisticated security, so reducing the configuration
effort should increase deployments.

I suggest that a negotiation mechanism be available but designed so that a
user can control it, or even disable it, through configuration. This way 
if a
user has some reason to be concerned that the negotiation mechanism won't 
work
correctly or some issues might be introduced by using such a mechanism, 
for
example if they are using devices from multiple vendors and don't trust 
those
devices to be interoperable, then the operator can carefully control the
authentication parameters.

Regards,
Michael

------ Original Message ------
Received: Thu, 13 Jan 2011 08:03:35 AM PST
From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: [karp] Negotiation

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: [email-masked]
Date: Wed, 19 Jan 2011 16:41:45 +0800

Hi Sam,

In my personal opinion, the approach you proposed is very suitable for 
manual keying case, and if we consider automated KMP and better security, 
negotiation is a MUST, and cancelling negotiation could be an option. 

What is your concerns, Gregory and other people?

Cheers,
Ellen (Xiaoping Liang)

2011-01-14 01:02

收件人
"Michael Barnes" <[email-masked]>
抄送
Sam Hartman <[email-masked]>, [email-masked]
主题
Re: [karp] Negotiation