Subject: [RTG-DIR] RtgDir review: draft-ietf-karp-threats-reqs-03

From: Ross Callon <[email-masked]>
Date: Thu, 11 Aug 2011 11:46:52 -0400

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-karp-threats-reqs-03.txt
Reviewer: Ross Callon
Review Date: August 11, 2011
Intended Status: Informational

Summary:

As currently written I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.

Comments:

The document is well written and very readable. I liked the way that the introduction placed this document in the overall context of securing the routing infrastructure. This makes it clear how this relates to other efforts (such as OPSEC, SIDR).

However, there are two requirements which are missing from section 3, that IMHO are necessary for any solution developed by KARP to be useable. There is also a requirement that could use additional explanation. It is possible that these requirements might be satisfied by solutions even if not listed in the requirements draft, but it is far better form to explicitly list essential requirements.

As the authors are well aware, two of the authors have changed email addresses and I personally don’t know how long their old addresses will still work. Their contact information should be updated in the draft.

Major Issues:

In section 3, requirements, there are two important requirements that appear to be missing (or perhaps only hinted in other requirements).

Any security protocol that is used, for example for automated key management, MUST be able to operate between multiple systems over a Broadcast media. For example, all of IS-IS, OSPF, and RIP have the ability to operate between multiple routers interconnected via a broadcast LAN, and LDP uses multicast for discovery over broadcast LANs. This needs to be supported for a security protocol to be useable by these routing protocols.

Any security protocol used to secure a routing protocol MUST NOT assume that the routing protocol is itself operating before the security protocol can operate. For example, this means that any protocol used to generate keys for operation of IS-IS or OSPF MUST NOT assume that it is possible to send any packet at all between two systems unless those two systems are directly connected at the link level.

This last point has a relationship with the requirement currently listed as number 24. It says “Therefore, proposed solutions SHOULD NOT require connections to external systems…”. However, note that if the proposed solution is being used to authenticate OSPF or IS-IS, and if OSPF or IS-IS will not bring up links until they are authenticated, and if the proposed solution requires sending any information to or getting any response from a not-directly-attached remote system, then it isn’t going to work. In this regard I think that the “SHOULD NOT” in requirement 24 is not strong enough, and the potential for deadlock should be explicitly mentioned.

Section 3, 9th bullet item (about DOS attacks): Routers are occasional intended victims of DDOS attacks, which may be aimed at the router’s control plane. As such it is normal for routers to make use of packet filters to protect the control plane, frequently implemented in silicon and operating at line rate (which may imply in core routers the ability to identify and discard hundreds of gigabits or even terabits of attack information without having any adverse effect on other aspects of router operation – other than the link bandwidth that the attack consumes prior to arriving at the router). We aren’t realistically likely to be checking cryptographic authentication and discarding unwanted traffic at terabit rates in routers, which implies that the existing packet filtering mechanisms need to be maintained, and that KARP is talking about *additional* protection, not a replacement for packet filters to protect against DDOS. Thus in defining security mechanisms there should be a strong preference for mechanisms that don’t hide nor encrypt the information that the router hardware is able to  inspect at full line rate for DDOS protection (such as IP addresses, and TCP ports). I think that a bit more text along the lines might be appropriate to be added to this bullet item.

Minor Issues:

What is the audience? Section 1.7 says that this includes “Routing Area working group chairs and participants”. Some of these may or may not know much about security. It therefore might be a good idea to define a few basic security terms in section 1.1, in particular “non-repudiation” is not likely to be universally understood. “Privacy”, ”authentication”, and “message integrity” seem more obvious, but might be worth defining also.

In section 3, requirement 16, I would put this as “MUST NOT” rather than “SHOULD NOT”. The failure to prioritize HELLO processing has at some points in the past had catastrophic implications on network operation. Any mechanism that breaks the prioritization of HELLOs is essentially unusable.

(very minor) In the second paragraph of section 1.4, you could mention that routing protocols are essentially real time distributed systems, in that there are routing protocol events that routers must perform in a specific time frame in order to prevent other systems from reacting in unfortunate ways.  Thus the need for “extensive tuning of software and hardware elements” as you state. As one example (which you probably don’t need to explicitly describe, but for the benefit of the authors) there have been times in the past where due to being very busy due to network events, a router has failed to send or to receive HELLO messages within the required time frame, and as a result routers have declared links down. This can result in additional routing protocol traffic which can exacerbate whatever event cause a router to be busy in the first place.

Nits:

In section 1.4, personally I would put “vastly- improved-over-current-security-but-admittedly-not-yet-best-security- possible” in quotes rather than writing this longish phrase with dashes. If doing this, then perhaps “best-security-possible” could also be in quotes. The point is easy to understand however as is (and makes sense).

Last paragraph of section 1.4, are we missing the word “and” before “TCP session resetting”?

Section 1.5, third numbered bullet: The first “sentence” of this is not actually a sentence. There is a verb missing. Do you mean “Ensure the deployability of the improved security solutions on currently running routing infrastructure equipment.”?

Section 1.5, fourth numbered bullet: You have wandered away from a parallel writing style for each numbered bullet in this section. The first two start with a sentence. The third starts with something that appears to be intended to be a sentence, but isn’t quite. The fourth starts with a heading “Operational deployability”. It would read better to maintain the same style in each bullet (either start the first three with a heading, or don’t start the fourth with a heading). I like the heading on this fourth bullet, and wonder whether you should come up with ones for the first three bullets. Alternately the heading on bullet four could be turned into a very short sentence, such as “Ensure operational deployability “.

Section 1.7, first bullet item: To me the term “Co-advisors” should be just “Advisors”.

Really minor, section 3, “Rouing Protocol”. Is “privacey” spelled currently in item 7 of section 3?

---

From: Ross Callon <[email-masked]>
Date: Fri, 12 Aug 2011 14:03:13 -0400

I think that we are close. Looking at your proposed new text relating to DOS attacks: 

  New mechanisms must resist DoS attacks described as in-scope in the
  threats section 2.1 above. Routers protect the control plane by
  implementing mechanisms to filter completely or rate limit traffic
  not required at the control plane level (i.e., unwanted traffic). 
  This is done by deep inspecting the packets and only accepting the
  legitimate ones. The new mechanisms shouldn't thus hide or encrypt
  the information carried in the control plane packets so that routers
  can inspect these packets at the line rate.

To me "deep inspection" is something that looks deeper than just the IP and transport layer headers, and that typically can't be done at full line rate on very fast interfaces. It would be lovely to do deep packet inspection and cryptographic authentication checking at full line rate on all interfaces on terabit routers, but this isn't likely to happen any time in the foreseeable future. Thus service provider routers need to do full line rate filtering on as much as can be done at full line rate, and might or might not also separately do deep inspection of packets that are headed for the control plane. We have certainly seen (as of several years ago, I assume that attacks have probably gotten worse) multi-gigabit attacks on the control plane of routers, which of course a gigabit Ethernet link to the control plane can't carry.

Thus I don't think that the sentence "This is done by deep inspecting the packets and only accepting the legitimate ones." is quite right.  I would be inclined to just remove this sentence since the previous sentence captures the point quite well. The next sentence already gets at the point that these filters should operate at full line rate. Typically (not universally in all routers) what the large routers can filter on at line rate includes the IP and transport (TCP or UDP) headers, and stuff below that (including incoming link), but does not include stuff above that in the stack. We might want to mention this, so that the paragraph becomes: 

  New mechanisms must resist DoS attacks described as in-scope in the
  threats section 2.1 above. Routers protect the control plane by
  implementing mechanisms to filter completely or rate limit traffic
  not required at the control plane level (i.e., unwanted traffic). 
  Typically line rate packet filtering capabilities look at information 
  at or below the IP and transport (TCP or UDP) headers, but do not 
  include higher layer information. Therefore the new mechanisms shouldn't   
  hide nor encrypt the information carried in the IP and transport layers
  in control plane packets.

Are you proposing that this paragraph be added to the existing text in requirement number 9? 

Also, this seems independent of the text relating to communicating with external systems. I will respond to that in a different email (after first getting a snack). 

thanks, Ross

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Gregory Lebovitz; [email-masked]
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,
 
Thanks for the detailed review!
	 
> This last point has a relationship with the requirement currently 
> listed as number 24. It says "Therefore, proposed solutions SHOULD
> NOT require connections to external systems...". However, note that if 
> the proposed solution is being used to authenticate OSPF or IS-IS, 
> and if OSPF or IS-IS will not bring up links until they are 
> authenticated, and if the proposed solution requires sending any 
> information to or getting any response from a not-directly-attached
> remote system, then it isn't going to work. In this regard I think 
> that the "SHOULD NOT" in requirement 24 is not strong enough, and
> the potential for deadlock should be explicitly mentioned.

Would it work if we replace SHOULD NOT with a MUST NOT?
	 
> Section 3, 9th bullet item (about DOS attacks): Routers are occasional intended 
> victims of DDOS attacks, which may be aimed at the router's control 
> plane. As such it is normal for routers to make use of packet 

[clipped]

> against DDOS. Thus in defining security mechanisms there should be a 
> strong preference for mechanisms that don't hide nor encrypt the 
> information that the router hardware is able to  inspect at full 
> line rate for DDOS protection (such as IP addresses, and TCP ports). 
> I think that a bit more text along the lines might be appropriate 
> to be added to this bullet item.  

How about something on these lines:

New mechanisms must resist DoS attacks described as in-scope in the threats section 2.1 above. Routers protect the control plane by implementing mechanisms to filter completely or rate limit traffic not required at the control plane level (i.e., unwanted traffic).  This is done by deep inspecting the packets and only accepting the legitimate ones. The new mechanisms shouldn't thus hide or encrypt the information carried in the control plane packets so that routers can inspect these packets at the line rate.

I have taken note of your other comments and those will get fixed in the next revision.

Cheers, Manav

---

From: Ross Callon <[email-masked]>
Date: Fri, 12 Aug 2011 15:00:53 -0400

Regarding requirement number 24, changing "should not" to "must not" does help a lot. However, it might be worth adding a bit of explanation. How about:

OLD

24.  The new authentication and security mechanisms should not rely
     on systems external to the routing system (the equipment that is
     performing forwarding).  In order to ensure the rapid
     initialization and/or return to service of failed nodes it is
     important to reduce reliance on these external systems to the
     greatest extent possible.  Therefore, proposed solutions SHOULD
     NOT require connections to external systems, beyond those
     directly involved in peering relationships, in order to return
     to full service.  It is however acceptable for the proposed
     solutions to require post initialization synchronization with
     external systems in order to fully synchronize the security
     information.

NEW

24.  The new authentication and security mechanisms should not rely
     on systems external to the routing system (the equipment that 
     is performing forwarding).  In order to ensure the rapid
     initialization and/or return to service of failed nodes it is
     important to reduce reliance on these external systems to the
     greatest extent possible. Also, it is necessary to avoid a 
     circular dependency between the security mechanisms and routing
     (which itself is required to deliver IP packets to any external 
     systems which are not directly connected at the link layer).
     Therefore, proposed solutions MUST NOT require connections to
     external systems, beyond those directly involved in peering
     relationships, in order to return to full service.  It is
     however acceptable for the proposed solutions to require post
     initialization synchronization with external systems in order to
     fully synchronize the security information.

Does this look okay to you? 

Thanks, Ross

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Gregory Lebovitz; [email-masked]
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,

	 

[clipped]

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 12 Aug 2011 14:38:32 +0530

Hi Ross,

	 

[clipped]

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 13 Aug 2011 04:15:27 +0530

Hi Ross,
 
> existing text in requirement number 9? 

Yes, I am proposing replacing requirement 9 with the above text.

Cheers, Manav

> 
> 
> Also, this seems independent of the text relating to 
> communicating with external systems. I will respond to that 
> in a different email (after first getting a snack). 
> 
> thanks, Ross
> 
> Cc: [email-masked]; 
> [email-masked]; 
> [email-masked]; Gregory Lebovitz; [email-masked]
> > listed as number 24. It says "Therefore, proposed solutions 
> SHOULD NOT 
> > require connections to external systems...". However, note 
> that if the 
> > proposed solution is being used to authenticate OSPF or 
> IS-IS, and if 
> > OSPF or IS-IS will not bring up links until they are authenticated, 
> > and if the proposed solution requires sending any information to or 
> > getting any response from a not-directly-attached remote 
> system, then 
> > it isn't going to work. In this regard I think that the 
> "SHOULD NOT" 
> > in requirement 24 is not strong enough, and the potential 
> for deadlock 
> > should be explicitly mentioned.
> 
> > Section 3, 9th bullet item (about DOS attacks): Routers are 
> occasional 
> > intended victims of DDOS attacks, which may be aimed at the 
> router's 
> > control plane. As such it is normal for routers to make use 
> of packet
> 
> [clipped]
> 
> > information that the router hardware is able to  inspect at 
> full line 
> > rate for DDOS protection (such as IP addresses, and TCP ports).
> > I think that a bit more text along the lines might be 
> appropriate to 
> > be added to this bullet item.
> 
> New mechanisms must resist DoS attacks described as in-scope 
> in the threats section 2.1 above. Routers protect the control 
> plane by implementing mechanisms to filter completely or rate 
> limit traffic not required at the control plane level (i.e., 
> unwanted traffic).  This is done by deep inspecting the 
> packets and only accepting the legitimate ones. The new 
> mechanisms shouldn't thus hide or encrypt the information 
> carried in the control plane packets so that routers can 
> inspect these packets at the line rate.
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 13 Aug 2011 04:16:44 +0530

> Does this look okay to you? 

Yes, it does. I will update the draft with this.

Cheers, Manav

---

From: Gregory Lebovitz <[email-masked]>
Date: Sat, 13 Aug 2011 00:10:28 -0700

Hey all.

Ross, the circular dependency issue is not really an issue. I remember you
raising it early on in the KARP formation process, and me explaining the
following, which was taken from the survey of about 7 operators I did before
I wrote the original text (which later became the drafts to forming KARP):

When operators bring up new routers, or bring up replaced/fixed routers,
they do so by having a human local to the device rack it, connect it to a
console server, and then send the coordinates to a NOC operator. Said NOC
operator then starts to build up the config on the device. A few static
routes, or a default route, is placed into the device first in order to test
basic network connectivity and to setup up secure, inband management. At
this point keys are often created for SSH use. Many other items are
configured on the device that have to do with OAM, and all are tested,
BEFORE dynamic routing is turned on. In other words, the device has to
function well on the network as a healthy host before it becomes a
forwarding agent. Once all this is clear and verified, then routing is
turned on protocol by protocol and confirmed.

The above process was ubiquitously followed by operators. NONE ever relied
on routing protocols for management connectivity, not at least at the point
of boot strapping. Any credentials or validating data that would need to be
fetched in order to secure the routing protocol would be loaded or fetched
BEFORE routing protocols were turned on, using default or static routes,
just as all other config / data is fetched at device bring up.

I recall when I explained this to you at the onset of all this work you said
something to the effect of, "Oh, I get it. That makes me feel much better.
So it's not really an issue then," and we moved on.

Having said all that, I'm not opposed to your NEW proposal below. If
everyone else agrees I would live with it. However, I will point out that a
healthy use of "SHOULD NOT" would contain a clear explanation of the
circumstance/condition under which it is acceptable to break the guidance,
and reminder that aside from such circumstance/condition, the guidance ought
be followed. I think both the OLD and NEW text already contained the
explanation of when requiring connections to external systems is acceptable:
 to require post-initialization synchronization "in order to fully
synchronize the security information." Thus, the SHOULD NOT was ok, because
we stated the condition under which it was reasonable to defy the SHOULD
NOT. Saying "MUST NOT" and then telling them when it's okay to break the
condition really is the same as a "SHOULD NOT", no? Would the following
address your concerns, and also have logic integrity:

NEW II

24.  The new authentication and security mechanisms should not rely
    on systems external to the routing system (the equipment that
    is performing forwarding).  In order to ensure the rapid
    initialization and/or return to service of failed nodes it is
    important to reduce reliance on these external systems to the
    greatest extent possible. Also, it is necessary to avoid a
    circular dependency between the security mechanisms and routing
    protocols whereby the operation of the security mechanism would
    require a routing protocol -- which we are trying to secure -- to
already
    be running in order to properly forward packets.
    Therefore, proposed solutions SHOULD NOT require connections to
    external systems, beyond those directly involved in peering
    relationships, in order to return to full service.  The condition under
    which it is acceptable for the proposed solutions to require connections
    to external systems is for post
    initialization synchronization with external systems, in order to
    fully synchronize the security information.

I think the above (1) makes your point about circular dependency, (2) makes
it clear the only time when the SHOULD NOT would be disobeyed, (3) has
logical integrity. Does it work for all you folks?

Hope it helps,
Gregory

On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon <[email-masked]> wrote:

> Regarding requirement number 24, changing "should not" to "must not" does
> help a lot. However, it might be worth adding a bit of explanation. How
> about:
>
> OLD
>
> Cc: [email-masked]; [email-masked];
> New mechanisms must resist DoS attacks described as in-scope in the threats
> section 2.1 above. Routers protect the control plane by implementing
> mechanisms to filter completely or rate limit traffic not required at the
> control plane level (i.e., unwanted traffic).  This is done by deep
> inspecting the packets and only accepting the legitimate ones. The new
> mechanisms shouldn't thus hide or encrypt the information carried in the
> control plane packets so that routers can inspect these packets at the line
> rate.
>

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

---

From: Gregory Lebovitz <[email-masked]>
Date: Sat, 13 Aug 2011 01:04:26 -0700

The text works for me.

One thing to consider, philosophically: I'm not sure we want to tell people
that just because some tools exist today that do FOO we shouldn't solve a
problem with BAR, because FOO and BAR may not work together. If BAR is
genuinely wonderful and adds enormous value to the system, then maybe BAR
ought to live, and FOO ought to morph. Practically applied to this
paragraph, perhaps it is more helpful to say the following:

"Therefore any new mechanism that would either hide or encrypt the
information carried in the IP and transport layers in control plane packets
would impair these existing filtering tools. Trade-offs must be described
and weighed to ensure the value and acceptability of the new mechanism far
surpasses that of the existing running tools that may be broken, and
preference should be to avoid breaking the existing tools."

Again, I can live with the below text; I'm not demanding my suggestion
above.

FWIW,
Gregory

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

---

From: Ross Callon <[email-masked]>
Date: Mon, 15 Aug 2011 09:18:07 -0400

Would a security protocol, for example used for automated key management, operate over the out of band management plane, or would it operate over the normal data plane, or between two systems directly attached at the link layer, or in some other way?

Ross

From: Gregory Lebovitz [mailto:[email-masked]]
Sent: Saturday, August 13, 2011 3:10 AM
To: Ross Callon
Cc: Bhatia, Manav (Manav); [email-masked]; [email-masked]; [email-masked]; Gregory Lebovitz; [email-masked]; [email-masked]
Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hey all.

Ross, the circular dependency issue is not really an issue. I remember you raising it early on in the KARP formation process, and me explaining the following, which was taken from the survey of about 7 operators I did before I wrote the original text (which later became the drafts to forming KARP):

When operators bring up new routers, or bring up replaced/fixed routers, they do so by having a human local to the device rack it, connect it to a console server, and then send the coordinates to a NOC operator. Said NOC operator then starts to build up the config on the device. A few static routes, or a default route, is placed into the device first in order to test basic network connectivity and to setup up secure, inband management. At this point keys are often created for SSH use. Many other items are configured on the device that have to do with OAM, and all are tested, BEFORE dynamic routing is turned on. In other words, the device has to function well on the network as a healthy host before it becomes a forwarding agent. Once all this is clear and verified, then routing is turned on protocol by protocol and confirmed.

The above process was ubiquitously followed by operators. NONE ever relied on routing protocols for management connectivity, not at least at the point of boot strapping. Any credentials or validating data that would need to be fetched in order to secure the routing protocol would be loaded or fetched BEFORE routing protocols were turned on, using default or static routes, just as all other config / data is fetched at device bring up.

I recall when I explained this to you at the onset of all this work you said something to the effect of, "Oh, I get it. That makes me feel much better. So it's not really an issue then," and we moved on.

Having said all that, I'm not opposed to your NEW proposal below. If everyone else agrees I would live with it. However, I will point out that a healthy use of "SHOULD NOT" would contain a clear explanation of the circumstance/condition under which it is acceptable to break the guidance, and reminder that aside from such circumstance/condition, the guidance ought be followed. I think both the OLD and NEW text already contained the explanation of when requiring connections to external systems is acceptable:  to require post-initialization synchronization "in order to fully synchronize the security information." Thus, the SHOULD NOT was ok, because we stated the condition under which it was reasonable to defy the SHOULD NOT. Saying "MUST NOT" and then telling them when it's okay to break the condition really is the same as a "SHOULD NOT", no? Would the following address your concerns, and also have logic integrity:

NEW II

    require a routing protocol -- which we are trying to secure -- to already

I think the above (1) makes your point about circular dependency, (2) makes it clear the only time when the SHOULD NOT would be disobeyed, (3) has logical integrity. Does it work for all you folks?

Hope it helps,
Gregory

On Fri, Aug 12, 2011 at 12:00 PM, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:
Regarding requirement number 24, changing "should not" to "must not" does help a lot. However, it might be worth adding a bit of explanation. How about:

OLD

NEW

Thanks, Ross

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gregory Lebovitz; [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,

[clipped]

Cheers, Manav

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 15 Aug 2011 09:40:18 -0400

While I admit that I don't do a lot of customer router debugging these days, my past experience has been that out-of-band OAM router access is common but certainly not universal. However, "SHOULD NOT" is probably strong enough wording to prefer KMPs not requiring connectivity to external systems over those that do. 

Thanks,
Acee

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Aug 2011 11:17:22 -0400

That would depend upon the security protocol.
Almost all of them assume at least reachability between the two parties 
(or n parties) involved.

Given that the structure we are using allows for manual keying as well 
as automated key management, we can cope out by noting that 
bootstrapping devices could be done using manual keys, and that during 
normal operation, these could then use AKM for new keys.

Also, some of what folks refer to as AKM uses preconfigured (even 
manually configured) base keys to bootstrap the peer AKM process.  So 
that would not have dependence upon the rest of the network being 
configured and operational.
Other folks use the term for other things.

I will also note that we have an explicit decision by the WG that the 
AKM shall be a separate component, not a modification of the routing 
system itself.  Unless we really want to re-open that can of worms, 
please think of that as a constraint.

Yours,
Joel

On 8/15/2011 9:18 AM, Ross Callon wrote:
> Would a security protocol, for example used for automated key
> management, operate over the out of band management plane, or would it
> operate over the normal data plane, or between two systems directly
> attached at the link layer, or in some other way?
>
> Ross
>
> *From:*Gregory Lebovitz [mailto:[email-masked]]
> *Sent:* Saturday, August 13, 2011 3:10 AM
> *To:* Ross Callon
> *Cc:* Bhatia, Manav (Manav); [email-masked];
> [email-masked]; [email-masked]; Gregory
> Lebovitz; [email-masked]; [email-masked]
> *Subject:* Re: reliance on external systems (req 24), RE: RtgDir review:
> draft-ietf-karp-threats-reqs-03
>
> Hey all.
>
> Ross, the circular dependency issue is not really an issue. I remember
> you raising it early on in the KARP formation process, and me explaining
> the following, which was taken from the survey of about 7 operators I
> did before I wrote the original text (which later became the drafts to
> forming KARP):
>
> they do so by having a human local to the device rack it, connect it to
> a console server, and then send the coordinates to a NOC operator. Said
> NOC operator then starts to build up the config on the device. A few
> static routes, or a default route, is placed into the device first in
> order to test basic network connectivity and to setup up secure, inband
> management. At this point keys are often created for SSH use. Many other
> items are configured on the device that have to do with OAM, and all are
> tested, BEFORE dynamic routing is turned on. In other words, the device
> has to function well on the network as a healthy host before it becomes
> a forwarding agent. Once all this is clear and verified, then routing is
> The above process was ubiquitously followed by operators. NONE ever
> relied on routing protocols for management connectivity, not at least at
> the point of boot strapping. Any credentials or validating data that
> would need to be fetched in order to secure the routing protocol would
> be loaded or fetched BEFORE routing protocols were turned on, using
> default or static routes, just as all other config / data is fetched at
> device bring up.
>
> I recall when I explained this to you at the onset of all this work you
> said something to the effect of, "Oh, I get it. That makes me feel much
> better. So it's not really an issue then," and we moved on.
>
> everyone else agrees I would live with it. However, I will point out
> that a healthy use of "SHOULD NOT" would contain a clear explanation of
> the circumstance/condition under which it is acceptable to break the
> guidance, and reminder that aside from such circumstance/condition, the
> guidance ought be followed. I think both the OLD and NEW text already
> contained the explanation of when requiring connections to external
> systems is acceptable: to require post-initialization synchronization
> "in order to fully synchronize the security information." Thus, the
> SHOULD NOT was ok, because we stated the condition under which it was
> reasonable to defy the SHOULD NOT. Saying "MUST NOT" and then telling
> them when it's okay to break the condition really is the same as a
> "SHOULD NOT", no? Would the following address your concerns, and also
> have logic integrity:
>
> NEW II
>
>
> I think the above (1) makes your point about circular dependency, (2)
> makes it clear the only time when the SHOULD NOT would be disobeyed, (3)
> has logical integrity. Does it work for all you folks?
>
> Hope it helps,
>
> Gregory
>
> Regarding requirement number 24, changing "should not" to "must not"
> does help a lot. However, it might be worth adding a bit of explanation.
> How about:
>
> OLD
>
> From: Bhatia, Manav (Manav) [mailto:[email-masked]
> <mailto:[email-masked]>]
> To: Ross Callon; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>;
> [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; Gregory Lebovitz; [email-masked]
> <mailto:[email-masked]>
> occasional intended
> implementing mechanisms to filter completely or rate limit traffic not
> required at the control plane level (i.e., unwanted traffic). This is
> done by deep inspecting the packets and only accepting the legitimate
> ones. The new mechanisms shouldn't thus hide or encrypt the information
> carried in the control plane packets so that routers can inspect these
> packets at the line rate.
>

---

From: Russ White <[email-masked]>
Date: Mon, 15 Aug 2011 20:43:31 -0400

> While I admit that I don't do a lot of customer router debugging these
> days, my past experience has been that out-of-band OAM router access is
> common but certainly not universal. However, "SHOULD NOT" is probably
> strong enough wording to prefer KMPs not requiring connectivity to
> external systems over those that do. 

OOB OAM access is pretty rare, in my experience. the best solution would
be one that works like a routing protocol --flooded to all interested
parties, or hop by hop, so routing isn't needed. On the other hand, if
you're going to deploy some form of automated key management, it doesn't
seem particular horrible to say, "and you need to have out of band
management. The alternative is to bring up routing in such a way that
each device along the current edge authenticates and brings up routing,
expanding the edge in the network by one hop in each time slice."
Bringing an entire network up seems like it would happen rarely enough
that this isn't too much of a restriction.

:-)

Russ

---

From: Ross Callon <[email-masked]>
Date: Mon, 15 Aug 2011 22:31:58 -0400

But if the key management protocol was running over the out of band management network, then which version of OSPF would it be generating keys for? If it were generating keys to be used for the version of OSPF running on its production network, then there is a clear bootstrapping path either initially or to recover from any bad state: first the OOB network comes up, then the keys are exchanged, then the regular network comes up.  If it were generating keys for the version that made the OOB network work, then what would happen if it got out of sync?

Didn't you sort of suggest below that if the key management protocol needs to talk to some external device, then the external device needs to - like the initial method's used to bring up the router - either be local to the router, or run over a separate OOB network? It seems to make sense to add the option of operating over a separate OOB network to the text that I was proposing.

In the early days of the Arpanet, there was one "event" where the entire network crashed, and the operators had to first fix only the router's which were adjacent to the network management station, then fix the ones which were adjacent to the one's already fixed, and recurse in this way through the network. I don't think that this is a method that we want to recommend as the normal method to recover from major events (it would seem to get progressively uglier as networks get bigger).

Ross

From: Bhatia, Manav (Manav) [mailto:[email-masked]]
Sent: Monday, August 15, 2011 10:06 AM
To: Ross Callon; Gregory Lebovitz
Cc: [email-masked]; [email-masked]; [email-masked]; Gregory Lebovitz; [email-masked]; [email-masked]
Subject: RE: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03

This imo can certainly happen. I used to know at least one big deployment in Europe that ran OSPF on its out-of-management plane - not sure if they still do. If we define a new KMP that secures OSPF, then it could certainly run over the OOB ports.

Cheers, Manav

________________________________
From: Ross Callon [mailto:[email-masked]]
Sent: Monday, August 15, 2011 6:48 PM
To: Gregory Lebovitz
Cc: Bhatia, Manav (Manav); [email-masked]; [email-masked]; [email-masked]; Gregory Lebovitz; [email-masked]; [email-masked]
Subject: RE: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03
Would a security protocol, for example used for automated key management, operate over the out of band management plane, or would it operate over the normal data plane, or between two systems directly attached at the link layer, or in some other way?

Ross

Hey all.

NEW II

Hope it helps,
Gregory

OLD

NEW

Thanks, Ross

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gregory Lebovitz; [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,

[clipped]

Cheers, Manav

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 15 Aug 2011 19:36:29 +0530

Cheers, Manav

Ross

Hey all.

NEW II

Hope it helps,
Gregory

OLD

NEW

Thanks, Ross

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gregory Lebovitz; [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,

[clipped]

Cheers, Manav

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

---

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 17 Aug 2011 23:19:30 -0700

inline...

On Mon, Aug 15, 2011 at 7:31 PM, Ross Callon <[email-masked]> wrote:

> But if the key management protocol was running over the out of band
> management network, then which version of OSPF would it be generating keys
> for? If it were generating keys to be used for the version of OSPF running
> on its production network, then there is a clear bootstrapping path either
> initially or to recover from any bad state: first the OOB network comes up,
> then the keys are exchanged, then the regular network comes up.  If it were
> generating keys for the version that made the OOB network work, then what
> would happen if it got out of sync?
>

GML> There are two issues here wrt the AKM operation: (1) How the
credentials and bootstrapping crypto inputs get on the device, and (2) how
peers find each other.

GML> For (1) the answer is the same as for how the device will receive
inputs in order to be securely managed:  the crypto inputs (e.g. for a
public key pair used for a self-signed cert, or in an SSH negotiation, or
PSK, or whatever) are either generated locally on the device via a console
connection at initial device bring up, or manually typed in (could be
cut-n-paste) via config lines, or via an uploaded config file. Once these
initial config elements are created/entered, then the AKM can be run
successfully.

GML> for (2) it will completely depend upon the particular routing protocol
and the solution we come up with for that routing protocol. However, since
the AKM is NOT DESIGNED INTO THE ROUTING PROTOCOL ITSELF, there can be
config associated with the AKM's operation which tells the device how to
reach a particular routing peer(s). Sometimes this might be "send the
message out this interface" sometimes it may be "send it to this IP address,
or that host name"... it will just depend on the specifics and
characteristics of the routing protocol being worked on.

GML> Does that make sense?

GML> Gregory

> ****
>
> ** **
>
> Didn’t you sort of suggest below that if the key management protocol needs
> to talk to some external device, then the external device needs to – like
> the initial method’s used to bring up the router – either be local to the
> router, or run over a separate OOB network? It seems to make sense to add
> the option of operating over a separate OOB network to the text that I was
> proposing. ****
>
> ** **
>
> In the early days of the Arpanet, there was one “event” where the entire
> network crashed, and the operators had to first fix only the router’s which
> were adjacent to the network management station, then fix the ones which
> were adjacent to the one’s already fixed, and recurse in this way through
> the network. I don’t think that this is a method that we want to recommend
> as the normal method to recover from major events (it would seem to get
> progressively uglier as networks get bigger). ****
>
> ** **
>
> Ross****
>
> ** **
>
> *From:* Bhatia, Manav (Manav) [mailto:[email-masked]]
> *Sent:* Monday, August 15, 2011 10:06 AM
> *To:* Ross Callon; Gregory Lebovitz
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; Gregory Lebovitz; [email-masked]; [email-masked]
>
> *Subject:* RE: reliance on external systems (req 24), RE: RtgDir review:
> draft-ietf-karp-threats-reqs-03****
>
> ** **
>
> This imo can certainly happen. I used to know at least one big deployment
> in Europe that ran OSPF on its out-of-management plane - not sure if they
> still do. If we define a new KMP that secures OSPF, then it could certainly
> run over the OOB ports.****
>
>  ****
>
> Cheers, Manav****
>
> ** **
> ------------------------------
>
> *From:* Ross Callon [mailto:[email-masked]]
> *Sent:* Monday, August 15, 2011 6:48 PM
> *To:* Gregory Lebovitz
> *Subject:* RE: reliance on external systems (req 24), RE: RtgDir review:
> draft-ietf-karp-threats-reqs-03****
>
> Would a security protocol, for example used for automated key management,
> operate over the out of band management plane, or would it operate over the
> normal data plane, or between two systems directly attached at the link
> layer, or in some other way? ****
>
> ** **
>
> Ross****
>
> ** **
>
> *From:* Gregory Lebovitz [mailto:[email-masked]]
> draft-ietf-karp-threats-reqs-03****
>
> ** **
>
> Hey all.****
>
> ** **
>
> ****
>   ****
> turned on protocol by protocol and confirmed.****
>
> ** **
>
> just as all other config / data is fetched at device bring up.****
>
> ** **
>
> better. So it's not really an issue then," and we moved on.****
>
> ** **
>
> address your concerns, and also have logic integrity:****
>
> ** **
>
> NEW II****
>
>
>     circular dependency between the security mechanisms and routing****
>
>     protocols whereby the operation of the security mechanism would ****
>
> already****
>     which it is acceptable for the proposed solutions to require
> connections****
>
>     to external systems is for post****
>
>     fully synchronize the security information. ****
>
>  ****
>
> logical integrity. Does it work for all you folks?****
>
> ** **
>
> Hope it helps,****
>
> Gregory****
>
> ** **
>
> ****
> Cheers, Manav****
> ****
> ** **
> Juniper Networks****

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

---

From: Brian Weis <[email-masked]>
Date: Thu, 18 Aug 2011 10:04:58 -0700

All,

I prefer the SHOULD NOT wording. Recall that multicast routing protocols (e.g., PIM) are independent from unicast routing, and as such security system mechanism for multicast routing protocols can rely on systems external to the routing system without worrying about a circular dependancy.

Thanks,
Brian

-- 
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Ross Callon <[email-masked]>
Date: Thu, 18 Aug 2011 14:15:35 -0400

I am coming to the conclusion that we want some combination of a SHOULD NOT, as well as a note that if the security protocols that are used to secure routing depends upon connecting to systems that are not direct neighbors of the routers, then there MUST be one or more options to ensure against circular dependencies.

Thus three examples of a way to ensure against circular dependencies might be (i) using a separate network so that the security protocols run out of band from the normal routing protocols, (ii) using unicast routing to allow exchange of security protocols in order to pass information needed to bootstrap multicast routing; (iii) Using routing internal to a routing domain (the IGP, either OSPF or IS-IS) to allow communication within that domain, in order to pass information used to operate BGP.

The current ("old") text is:

OLD

We might for example add to this an additional new paragraph:

NEW (add to the above):

    If authentication and security mechanisms rely on systems external to the routing
    system, then there MUST be one or more options available to avoid circular
    dependencies. For example, it is not acceptable to have the operation of OSPF
    within a routing domain depend upon correct operation of a security protocol,
    have correct operation of the security protocol depend upon the ability to
    exchange IP packets between remote systems, and have the ability to exchange
    IP packets between remote systems depend upon correct operation of the same
    instance of OSPF within the same routing domain. However, it is okay to have
    operation of multicast routing and/or interdomain routing depend upon operation
    of a security protocol, which depends upon exchange of IP packets between
    remote systems, which depends upon the correct operation of OSPF for unicast
    routing. Similarly it would be okay to have the operation of OSPF depend upon
    a security protocol, which in turn uses an out of band network to exchange
    information with remote systems.

Ross

From: Brian Weis [mailto:[email-masked]]
Sent: Thursday, August 18, 2011 1:05 PM
To: Gregory Lebovitz
Cc: Ross Callon; Bhatia, Manav (Manav); [email-masked]; [email-masked]; [email-masked]; Gregory Lebovitz; [email-masked]; [email-masked]
Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03

All,

Thanks,
Brian

NEW II

Hope it helps,
Gregory

OLD

NEW

Thanks, Ross

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gregory Lebovitz; [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,

[clipped]

Cheers, Manav

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

--
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]<mailto:[email-masked]>

---

From: Russ White <[email-masked]>
Date: Sun, 21 Aug 2011 15:12:30 -0400

> Ok by me. We are using a SHOULD NOT, and explaining why it's a SHOULD
> NOT by describing a case or two where it is needed. This, IMHO, is the
> right way to use as SHOULD NOT. Thanks for the good team work.

I'm fine with this, as well.

:-)

Russ

---

From: Ross Callon <[email-masked]>
Date: Sun, 21 Aug 2011 20:39:31 -0400

Greg;

I think that the first issue we need to deal with is what text to put into the requirements document. It is not obvious to me how to reduce your  discussion of possible solutions into text for the requirements.

thanks, Ross

From: Gregory Lebovitz [mailto:[email-masked]]
Sent: Thursday, August 18, 2011 2:20 AM
To: Ross Callon
Cc: Bhatia, Manav (Manav); [email-masked]; [email-masked]; [email-masked]; Gregory Lebovitz; [email-masked]; [email-masked]
Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03

inline...
On Mon, Aug 15, 2011 at 7:31 PM, Ross Callon <[email-masked]<mailto:[email-masked]>> wrote:
But if the key management protocol was running over the out of band management network, then which version of OSPF would it be generating keys for? If it were generating keys to be used for the version of OSPF running on its production network, then there is a clear bootstrapping path either initially or to recover from any bad state: first the OOB network comes up, then the keys are exchanged, then the regular network comes up.  If it were generating keys for the version that made the OOB network work, then what would happen if it got out of sync?

GML> There are two issues here wrt the AKM operation: (1) How the credentials and bootstrapping crypto inputs get on the device, and (2) how peers find each other.

GML> For (1) the answer is the same as for how the device will receive inputs in order to be securely managed:  the crypto inputs (e.g. for a public key pair used for a self-signed cert, or in an SSH negotiation, or PSK, or whatever) are either generated locally on the device via a console connection at initial device bring up, or manually typed in (could be cut-n-paste) via config lines, or via an uploaded config file. Once these initial config elements are created/entered, then the AKM can be run successfully.

GML> for (2) it will completely depend upon the particular routing protocol and the solution we come up with for that routing protocol. However, since the AKM is NOT DESIGNED INTO THE ROUTING PROTOCOL ITSELF, there can be config associated with the AKM's operation which tells the device how to reach a particular routing peer(s). Sometimes this might be "send the message out this interface" sometimes it may be "send it to this IP address, or that host name"... it will just depend on the specifics and characteristics of the routing protocol being worked on.

GML> Gregory

Ross

From: Bhatia, Manav (Manav) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 15, 2011 10:06 AM
To: Ross Callon; Gregory Lebovitz
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gregory Lebovitz; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Cheers, Manav

________________________________
From: Ross Callon [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 15, 2011 6:48 PM
To: Gregory Lebovitz
Cc: Bhatia, Manav (Manav); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gregory Lebovitz; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03
Would a security protocol, for example used for automated key management, operate over the out of band management plane, or would it operate over the normal data plane, or between two systems directly attached at the link layer, or in some other way?

Ross

From: Gregory Lebovitz [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, August 13, 2011 3:10 AM
To: Ross Callon
Cc: Bhatia, Manav (Manav); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gregory Lebovitz; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: reliance on external systems (req 24), RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hey all.

NEW II

Hope it helps,
Gregory

OLD

NEW

Thanks, Ross

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 12, 2011 5:09 AM
To: Ross Callon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Gregory Lebovitz; [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir review: draft-ietf-karp-threats-reqs-03

Hi Ross,

[clipped]

Cheers, Manav

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

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

---

From: Gregory Lebovitz <[email-masked]>
Date: Sun, 21 Aug 2011 08:54:17 -0700

Ok by me. We are using a SHOULD NOT, and explaining why it's a SHOULD NOT by
describing a case or two where it is needed. This, IMHO, is the right way to
use as SHOULD NOT. Thanks for the good team work.

On Thu, Aug 18, 2011 at 11:15 AM, Ross Callon <[email-masked]> wrote:

> I am coming to the conclusion that we want some combination of a SHOULD
> NOT, as well as a note that if the security protocols that are used to
> secure routing depends upon connecting to systems that are not direct
> neighbors of the routers, then there MUST be one or more options to ensure
> against circular dependencies. ****
>
> ** **
>
> Thus three examples of a way to ensure against circular dependencies might
> be (i) using a separate network so that the security protocols run out of
> band from the normal routing protocols, (ii) using unicast routing to allow
> exchange of security protocols in order to pass information needed to
> bootstrap multicast routing; (iii) Using routing internal to a routing
> domain (the IGP, either OSPF or IS-IS) to allow communication within that
> domain, in order to pass information used to operate BGP. ****
>
> ** **
>
> The current (“old”) text is: ****
>
> ** **
>
> OLD****
>
> ** **
>
> 24.  The new authentication and security mechanisms should not rely****
>
>     on systems external to the routing system (the equipment that is****
>
>     performing forwarding).  In order to ensure the rapid****
>
>     initialization and/or return to service of failed nodes it is****
>
>     important to reduce reliance on these external systems to the****
>
>     greatest extent possible.  Therefore, proposed solutions SHOULD****
>
>     NOT require connections to external systems, beyond those****
>
>     directly involved in peering relationships, in order to return****
>
>     to full service.  It is however acceptable for the proposed****
>
>     solutions to require post initialization synchronization with****
>
>     external systems in order to fully synchronize the security****
>
>     information.****
>
> ** **
>
> We might for example add to this an additional new paragraph: ****
>
> ** **
>
> NEW (add to the above): ****
>
> ** **
>
>     If authentication and security mechanisms rely on systems external to
> the routing****
>
>     system, then there MUST be one or more options available to avoid
> circular ****
>
>     dependencies. For example, it is not acceptable to have the operation
> of OSPF****
>
>     within a routing domain depend upon correct operation of a security
> protocol,****
>
>     have correct operation of the security protocol depend upon the ability
> to ****
>
>     exchange IP packets between remote systems, and have the ability to
> exchange****
>
>     IP packets between remote systems depend upon correct operation of the
> same****
>
>     instance of OSPF within the same routing domain. However, it is okay to
> have ****
>
>     operation of multicast routing and/or interdomain routing depend upon
> operation****
>
>     of a security protocol, which depends upon exchange of IP packets
> between ****
>
>     remote systems, which depends upon the correct operation of OSPF for
> unicast ****
>
>     routing. Similarly it would be okay to have the operation of OSPF
> depend upon ****
>
>     a security protocol, which in turn uses an out of band network to
> exchange****
>
>     information with remote systems. ****
>
> ** **
>
> Ross****
>
> ** **
>
> *From:* Brian Weis [mailto:[email-masked]]
> *Sent:* Thursday, August 18, 2011 1:05 PM
> *To:* Gregory Lebovitz
> *Cc:* Ross Callon; Bhatia, Manav (Manav); [email-masked];
> All,****
> I prefer the SHOULD NOT wording. Recall that multicast routing protocols
> (e.g., PIM) are independent from unicast routing, and as such security
> system mechanism for multicast routing protocols can rely on systems
> external to the routing system without worrying about a circular dependancy.
> ****
>
> ** **
>
> Thanks,****
>
> Brian****
>
> ** **
>
> On Aug 13, 2011, at 12:10 AM, Gregory Lebovitz wrote:****
>
> Hey all.****
>
> ** **
>
> Email: [email-masked]****

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

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 22 Aug 2011 05:57:03 +0530

Hi Ross,

This looks ok to me. If everyone agrees then i shall update the draft 
with the below addition.

Cheers, Manav

On 8/18/2011 11:45 PM, Ross Callon wrote:
> neighbors of the routers, then there MUST be one or more options to
> ensure against circular dependencies.
>
> Thus three examples of a way to ensure against circular dependencies
> might be (i) using a separate network so that the security protocols run
> out of band from the normal routing protocols, (ii) using unicast
> routing to allow exchange of security protocols in order to pass
> information needed to bootstrap multicast routing; (iii) Using routing
> internal to a routing domain (the IGP, either OSPF or IS-IS) to allow
> communication within that domain, in order to pass information used to
> operate BGP.
>
> The current (“old”) text is:
>
> OLD
>
> the routing
> protocol,
> have
> operation
> unicast
> *From:*Brian Weis [mailto:[email-masked]]
>     Ross, the circular dependency issue is not really an issue. I
>     remember you raising it early on in the KARP formation process, and
>     me explaining the following, which was taken from the survey of
>     about 7 operators I did before I wrote the original text (which
>     later became the drafts to forming KARP):
>
>     When operators bring up new routers, or bring up replaced/fixed
>     routers, they do so by having a human local to the device rack it,
>     connect it to a console server, and then send the coordinates to a
>     NOC operator. Said NOC operator then starts to build up the config
>     on the device. A few static routes, or a default route, is placed
>     into the device first in order to test basic network connectivity
>     and to setup up secure, inband management. At this point keys are
>     often created for SSH use. Many other items are configured on the
>     device that have to do with OAM, and all are tested, BEFORE dynamic
>     routing is turned on. In other words, the device has to function
>     well on the network as a healthy host before it becomes a forwarding
>     agent. Once all this is clear and verified, then routing is turned
>     on protocol by protocol and confirmed.
>
>     relied on routing protocols for management connectivity, not at
>     least at the point of boot strapping. Any credentials or validating
>     data that would need to be fetched in order to secure the routing
>     protocol would be loaded or fetched BEFORE routing protocols were
>     turned on, using default or static routes, just as all other config
>     / data is fetched at device bring up.
>
>     I recall when I explained this to you at the onset of all this work
>     you said something to the effect of, "Oh, I get it. That makes me
>     feel much better. So it's not really an issue then," and we moved on.
>
>     that a healthy use of "SHOULD NOT" would contain a clear explanation
>     of the circumstance/condition under which it is acceptable to break
>     the guidance, and reminder that aside from such
>     circumstance/condition, the guidance ought be followed. I think both
>     the OLD and NEW text already contained the explanation of when
>     requiring connections to external systems is acceptable: to require
>     post-initialization synchronization "in order to fully synchronize
>     the security information." Thus, the SHOULD NOT was ok, because we
>     stated the condition under which it was reasonable to defy the
>     SHOULD NOT. Saying "MUST NOT" and then telling them when it's okay
>     to break the condition really is the same as a "SHOULD NOT", no?
>     Would the following address your concerns, and also have logic
>     integrity:
>
>     NEW II
>
>
>     I think the above (1) makes your point about circular dependency,
>     (2) makes it clear the only time when the SHOULD NOT would be
>     disobeyed, (3) has logical integrity. Does it work for all you folks?
>
>     Hope it helps,
>
>     Gregory
>
>     does help a lot. However, it might be worth adding a bit of
>     explanation. How about:
>
>     OLD
>
>     <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; Gregory Lebovitz;
>     [email-masked] <mailto:[email-masked]>
> Email: [email-masked] <mailto:[email-masked]>
>