Subject: [RPSEC] proposed message to the IESG

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Jan 2005 10:35:01 -0500

Folks,

Here is the text I plan to send to the IESG, based on previous list 
discussions.  Please let me know if anyone would like changes or 
additions to the text, so it can be sent to the IESG soon.

Thanks,

Steve
--------

Members of the IESG:

I a writing this message, with the concurrence of the WG chairs, 
because the RPSEC working group has reached an impasse in our efforts 
to develop a security requirements document for BGP. Specifically, 
the WG has not been able to agree on the appropriate basis for 
deriving the requirements.

I have argued that the current version of the BGP spec (XXX) should 
form the primary basis for developing security requirements for BGP. 
This is not to say that all aspects of these requirements must be 
derived from that document, but that it should provide the base 
rationale for deriving most requirements. Some requirements, e.g., 
having to do with deployment and performance considerations, cannot 
be derived from the BGP spec. For these requirements it is 
appropriate and necessary to rely on operational experience, 
published analyses, etc.

In contrast, Russ White, a co-chair of the WG and a contributor to 
this RPSEC document, has asserted that operational experience should 
be the primary driver for the requirements document. Russ has stated 
that the BGP spec cited above does not accurately reflect BGP 
implementation and deployment patterns, and thus is not a suitable 
basis for the security requirements document that the WG is slated to 
develop. 

In our discussions on the WG list, I cited a number of quotes from 
the BGP spec in support of the sort of requirements that I think the 
document should embody. Russ has stated that many of these do not 
reflect BGP implementation and deployment, hence his insistence on a 
different basis for requirements development. I have objected because 
Russ has not been able to cite IETF-approved documents that describe 
the basis he supports.

I feel this disagreement in RPSEC raises a serious issues since this 
version of the BGP spec is slated to become a full standard. BGP is a 
product of the IDR WG, part of the same area (Routing) where the 
RPSEC work is taking place. It seems inappropriate for the IETF to 
adopt a BGP security requirements document that employs rationale 
that conflicts with the BGP spec, especially when both are developed 
in the same area.

If the IESG agrees that a BGP requirements document developed in the 
Routing area should be based on the BGP spec produced  by the same 
area, then it may be necessary to revisit the current version of the 
BGP spec to address the topics that Russ has identified as not 
consistent with BGP implementation and practice. Alternatively, the 
IESG might decide that the BGP security requirements document should 
be based primarily on operational considerations, in which case I 
suggest that the WG is more appropriately homed in the Operations 
(vs. Routing) area, and the focus might be a BCP-style document.

Thanks for taking the time to review this matter.

Steve Kent

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Blaine Christian <[email-masked]>
Date: Thu, 20 Jan 2005 11:10:27 -0500

Hello Steve,

I am concerned about your assertion that the draft does not follow the BGP
spec.  I have avoided stepping into the fray with you and Russ going at it.
But can you clarify, for me, exactly what parts of the BGP spec are being
ignored or changed in this draft?  I have been working with BGP for many
years and I could not find a spot where the document did not match reality
or the needs of the operators.

This document is intended to present a set of requirements from the operator
community to the folks creating the standards (which is why it is tracking
towards informational).

Regards,

Blaine

On 1/20/05 10:35 AM, "Stephen Kent" <[email-masked]> wrote:

> discussions.  Please let me know if anyone would like changes or additions to
> the text, so it can be sent to the IESG soon.
> 
> Thanks,
> 
> Steve
> --------
> 
> Members of the IESG:
> 
> I a writing this message, with the concurrence of the WG chairs, because the
> RPSEC working group has reached an impasse in our efforts to develop a
> security requirements document for BGP. Specifically, the WG has not been able
> to agree on the appropriate basis for deriving the requirements.
> 
> I have argued that the current version of the BGP spec (XXX) should form the
> primary basis for developing security requirements for BGP. This is not to say
> that all aspects of these requirements must be derived from that document, but
> that it should provide the base rationale for deriving most requirements. Some
> requirements, e.g., having to do with deployment and performance
> considerations, cannot be derived from the BGP spec. For these requirements it
> is appropriate and necessary to rely on operational experience, published
> analyses, etc.
> In contrast, Russ White, a co-chair of the WG and a contributor to this RPSEC
> document, has asserted that operational experience should be the primary
> driver for the requirements document. Russ has stated that the BGP spec cited
> above does not accurately reflect BGP implementation and deployment patterns,
> and thus is not a suitable basis for the security requirements document that
> the WG is slated to develop.
> 
> In our discussions on the WG list, I cited a number of quotes from the BGP
> spec in support of the sort of requirements that I think the document should
> embody. Russ has stated that many of these do not reflect BGP implementation
> and deployment, hence his insistence on a different basis for requirements
> development. I have objected because Russ has not been able to cite
> IETF-approved documents that describe the basis he supports.
> 
> I feel this disagreement in RPSEC raises a serious issues since this version
> of the BGP spec is slated to become a full standard. BGP is a product of the
> IDR WG, part of the same area (Routing) where the RPSEC work is taking place.
> It seems inappropriate for the IETF to adopt a BGP security requirements
> document that employs rationale that conflicts with the BGP spec, especially
> when both are developed in the same area.
> 
> If the IESG agrees that a BGP requirements document developed in the Routing
> area should be based on the BGP spec produced  by the same area, then it may
> be necessary to revisit the current version of the BGP spec to address the
> topics that Russ has identified as not consistent with BGP implementation and
> practice. Alternatively, the IESG might decide that the BGP security
> requirements document should be based primarily on operational considerations,
> in which case I suggest that the WG is more appropriately homed in the
> Operations (vs. Routing) area, and the focus might be a BCP-style document.
> 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 20 Jan 2005 14:05:04 +1837

Blaine,

> spec.  I have avoided stepping into the fray with you and Russ going at it.

Work responsibilities have kept me from commenting on this thread
directly, but I've had some offline conversations with a few people.

My specific concern is that the key items of contention between Russ
and Steve get summarized and presented to the IESG.  I do think Steve
is being a bit overly broad regarding "following the spec", but I
also think Russ has been a bit overly broad in some of his comments
about the spec and reality not matching up.  

I will take a moment to state on this list that many of the
items under contention are items I also had contention with Russ on
the bgpsecreq list.  Steve doesn't stand alone on many of them.

Some of the items under contention are "what elements of the BGP-4 protocol
are we trying to secure" and "does securing this element actually provide
security".  There are also operational conflicts, namely centralization
of the security infrastructure (vs. distributed) and also (forgive
me if I'm misusing the term) trust anchors.

I believe many of the operational issues can be addressed in the
solution-space portion of this exercise.  However, it may be necessary
to articulate the problem-space sufficiently to allow various choices
to be made.

However, the elements of security within the protocol are under
contention.  This is where I'd suggest focusing the IESG's attention.
To give a specific example, the value of securing the AS_PATH and
the method by which is secured.

I highly recommend that the bgpsecreq content be made available
if it is not already available.

-- 
Jeff Haas 
NextHop Technologies

---

From: Blaine Christian <[email-masked]>
Date: Thu, 20 Jan 2005 14:53:00 -0500

Hi Jeff,

That makes sense.  What I have been trying to do, at least on a personal
level, is be completely agnostic on the solution and focus on the needs of
the folks running existing BGP implementations.

Steve/Russ/Jeff, can we give one more shot at discussion with a bit more
participation on my part?  I truly have no side in this. Except, perhaps,
the side of the operators.

If we have to go to mediation I think we should provide a good chunk of
detail on the specific issues under contention.  If the BGP spec is violated
by the draft then we need to highlight the specific section that violates
the spec.  If the content of the draft is such that it belongs in a separate
working group then we need to identify why it does not match with the rpsec
charter.

I do recall seeing some thoughts that perhaps this draft is focused on a
specific solution.  If I could get the exact text that appears to do that
along with the explanation (I apologize if someone has to redo this) I would
appreciate it. 

The draft is a working group document now and is available at

http://www.ietf.org/html.charters/rpsec-charter.html

This is still a draft and belongs to the entire working group! So if we have
a chorus of voices on the thread saying something needs to be changed I am
happy to do so.  

Regards,

Blaine

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 20 Jan 2005 15:18:45 -0500

Blaine,

> the side of the operators.

Might I suggest starting with any thread that has a tree width > 4. :-)

> detail on the specific issues under contention.

If I might make a suggestion, it would probably be best if you (or,
in this case, not the parties under contention) make an attempt to
summarize the items of contention and the argument to either side.
If you, as an informed person, are unable to untangle the nature of
the items under contention, each side has failed to make themselves clear.

There's no sense in asking IESG to do this for us.

> If the BGP spec is violated
> the spec.

This is also one of the items under contention.  Our general desire
is not change the properties of BGP in general or specific.  For example,
the reluctance to touch the format of the Update message immediately
precludes certain solution-spaces (or has a very good chance of doing so).
More important, IMO, is to make sure we don't violate the semantics of
the information currently carry in BGP-4; rather, we should make sure
we only extend them.

The implicit meaning of some of the protocol semantics are part of the
contention.  Unfortunately, so is BGP-4's relationship with CIDR
and address allocation and delegation strategies.

-- 
Jeff Haas 
NextHop Technologies

---

From: Blaine Christian <[email-masked]>
Date: Thu, 20 Jan 2005 15:58:53 -0500

Hey Jeff,

Fair enough...  I will address through the specific points that Steve raised
as problems for the IESG.

Perhaps we can take the points one at a time.  As I see it there appear to
be two points of contention.

1. Draft not in the charter:  The premise for this argument appears to be
that by including requirements to cope with current operational practices
the draft falls under the wrong working group.  I read the charter and it
does not state that operational requirements are verboten.  The draft seems
to fall under the charter.

2. BGP spec not followed: I believe the crux of this discussion is that by
adding additional requirements to the way BGP currently works (to take into
account operational practice) we are improperly specifying the requirements.
However, ensuring that we preserve most of the current, established,
practice seems like a valid requirement to me.

Is the discussion revolving around the "extra" BGP attributes?  If so, it is
my perception that all transitive attributes MUST be protected via the
security mechanism.  My assumption, and I should be corrected if I am wrong,
was that MD5/IPSec type mechanisms would be sufficient for attributes that
are usually non-transitive (communities/localpref etc...).  Actually, since
I am also the guy pushing for one key so I don't see why the mechanism can't
directly protect both types of attributes.  What is wrong with that
argument?

Did I get your arguments right?  Russ/Steve?

BTW, I do not think we should care, too much, if the requirements document
states that the current implementation of BGP RFC needs work to bring it
into operational reality (or vice versa).  If I take the BGP spec and
compare it to the SIP spec it is quite an amazing site.  The SIP spec has an
incredible amount of detail while BGP is really quite loose.  It has been a
source of constant amazement to me that implementations actually work with
each other.  The fact that folks have implemented in ways that are not
strictly within the RFC boundaries is no surprise.

Regards,

Blaine

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 20 Jan 2005 16:25:05 -0500

Blaine,

> to fall under the charter.

I do not pretend to speak for Yakov or Sue (who is on this list) or the
IDR working group.  IMO, defining the security requirements for BGP
is within the rpsec charter.  Defining recommended protocol or operational
changes to BGP is also within charter.  

Defining the actual protocol level changes to BGP is at best
a cross-functional work item.  IMO, most of the work would be done in IDR
and it would be rpsec's responsibility to say "this doesn't do what
we wanted".

> 2. BGP spec not followed: 

I'll defer this to the other parties and try to stick to specifics since
that fits the ADHD way I'm following this group at the moment.

> If so, it is
> security mechanism.

Must they?
What is to be protected?
What does "protect" mean?

I think these two last questions form the core of our arguments.  However,
it is difficult to articulate each of these without delving into solutions.

> My assumption, and I should be corrected if I am wrong,
> are usually non-transitive (communities/localpref etc...).

Communities are transitive. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Tony Tauber <[email-masked]>
Date: Thu, 20 Jan 2005 16:54:06 -0500

> additions to the text, so it can be sent to the IESG soon.

<snip>

> (vs. Routing) area, and the focus might be a BCP-style document.

Hi Steve,

Perhaps I could help boil down what I see some of the basic questions
being.  Your sentence begining with "Alternatively..." combined with
Blaine's plea of "hey, I'm just an operator" (paraphrase mine) in this
thread crystalized something for me.

Operators want to secure inter-domain routing, not necessarily BGP.

Their requirements are essentially pragmatic, though some commercial
concerns (eg. strong unilateral control, possible obsfucation of
routing/interconnection policies) sneak in.

Is framing the problem as "securing BGP" appropriate?

We've been striving (at least I keep advising) to focus on
requirements, not solutions.  Perhaps seeing BGP or some variant or
add on to it as necessarily the solution is slightly constraining.

That being said, it's likely that the solution will somehow involve
BGP and, since that's an IETF protocol, changes to it ought to happen
in the IETF.  OTOH, if people figure some way to operationally work
around it, that happens outside the IETF.

My understanding/experience is that this organic process is what
happened to cause the earlier BGP-4 spec to become out of steop with
deployed reality; hence the effort to revise the spec in reverse.

My guess (and I'm no longer an ISP operator) is that we could see
something similar happen here should the IETF get too bogged down in
figuring out which Area work gets done rather than getting the work done.

Now, I don't want to come across as wedded to the idea that the RPSEC
WG or even the IETF has to be the ones to solve this problem; if it
gets done some other way, hopefully the users will benefit (eg. good
technology w/good interoperability).

All this being said, I think you've raised a great over-arching point
in the discussions we've had heretofore which I'll paraprhase thus:

---

Beware that the permissiveness of various deployment options can
compromise the resulting security.  It necessarily increases
complexity, for instance, and thus becomes more difficult to
understand, manage, and enforce.

---

This notion might run counter to a "give the people what they want"
approach to deriving requirements from Operators practical concerns.

I respect your experience and expertise in the security field and only
wish we had a greater range of voices from those who have such
experience.

Our problem has been that we're stuck in something of a culture gap
and things are devolving into a winner-take-all atmosphere that's
becoming toxic.  I don't know that the we need too take it the IESG or
if they could solve the problem (getting a useful improvement to routing
security).  If they could somehow, I'd welcome it, but this problem is
truly difficult.

OK, sorry for the rambling mail.

Tony

---

From: Blaine Christian <[email-masked]>
Date: Thu, 20 Jan 2005 17:01:23 -0500

> and it would be rpsec's responsibility to say "this doesn't do what

Sounds correct to me...

> that fits the ADHD way I'm following this group at the moment.

Haha, you are not the only one...  I have no idea why I submit myself to the
sort of abuse this type of work entails.

>> my perception that all transitive attributes MUST be protected via the

That is what the requirement says at this point...

> What is to be protected?

I believe that all the attributes can be protected with one of the two
mechanisms (either a lock down of the BGP session via some signing mechanism
or the use of a trust mechanism to ascertain the validity of the
information).  I still have this gnawing gut feeling that the two should be
one and the same (one key per AS).  Session security should be all about
ensuring the relationship between two BGP peers and prefix/AS security
should be all about ensuring the validity of received routes.

> What does "protect" mean?

Always a good question.  Protect against operator idiocy (never).  Protect
against malicious advertisements or theft of prefix space, hopefully.

> Communities are transitive. :-)

<me>getting ready to hit Jeff with a mackeral</me>.  That is why I said
usually... <grin>.  Most of the big Internet operators drop all communities
except for the ones specifically meant for their networks.  If the
communities are dropped across the Internet operators as a general rule then
the attributes are significantly less transitive than things like AS path
and NLRI.   It could also be said that the ability to advertise less
specific blocks pretty much makes the AS Path and NLRI non-transitive as
well.  However, typically, the aggregator is the owner so the anchor is
usually in a place that still makes sense.

Regards,

Blaine

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Jan 2005 10:08:08 -0500

Tony,

> Operators want to secure inter-domain routing, not necessarily BGP.

We may have a procedural issue here.

I agree that securing inter-domain routing is a good goal.  That goal
says more than securing BGP, particularly in the sense that we care
about securing operational practices beyond just the security of the
BGP-4 protocol.

However, what we have for inter-domain routing is BGP-4.  

We should be very careful to not try to be overly broad in our goals.
One consequence of being overly broad is to say "we don't care about BGP"
and to consider a completely new protocol.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Jan 2005 10:18:43 -0500

Blaine,

> should be all about ensuring the validity of received routes.

To pick this example, were I to want to make implementation choices
for protecting a session, I'd probably use some private key cryptographic
mechanism.  For transitive attributes, I'd probably want something
public key.  Those are details we shouldn't get bogged down on.

Far
more important is identifying the components of information that we're
trying to secure and what we mean by securing them and what securing
them will actually accomplish.  This will suggest solutions and also
our cost benefit tradeoffs.

> usually... <grin>.

I was intentionally (ahem) baiting you.

Part of the point here is that while many of us are aware that 
communities are operationally sanitized, sometimes to the excess
of "drop everything at the border that's not mine", this represents
practice.  This doesn't represent what the BGP protocol is capable of.

By a slightly better example, extended communities are also transitive.
However, data inside of them are intentionally non-transitive when
the extended community mechanism is understood by the BGP speaker.

Security implication: Whose behavior do you enforce?  Transitive or
non-transitive - path attribute transitivity or path attribute semantic
transitivity?

One of the challenges of securing things at the protocol level vs.
the operational level is that if we take the most restrictive path,
we potentially take protocol-valid things people do and remove
them as options.  In essence our question is, "Do we wish to change
existing protocol semantics?"

Arguments can be made either direction.

-- 
Jeff Haas 
NextHop Technologies

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jan 2005 10:54:08 -0500

Blaine,

I did no say that the current draft of the security requirements 
document does not follow the BGP spec. I will send a separate message 
addressing that issue, later.

What  said is that we are at an impasse re what to use as a basis for 
the requirements. I say this based on the extended discussions on the 
list with Russ, in which he said, repeatedly, that using the BGP spec 
as the primary basis for the requirements document is inappropriate.

Russ began making these comments in late December, when I responded 
to his comments on the current draft. (In fact, I never managed to 
get around to commenting on the draft itself, because of all the time 
spent arguing wit Russ over his and my suggested changes!) I proposed 
text in a message on 12/28/04 that I thought was appropriate for the 
draft, and I explained why, i.e., because it was traceable to the BGP 
spec. That triggered an intense discussion on the list (between Russ 
and me) that lasted for over a week.

If we agree that the BGP spec is the starting point for security 
requirements, then we have an objective basis for deciding whether 
proposed text is appropriate or not. That is why I have pursued this 
issue.

On 1/5 I sent a message that contained a lot of excerpts from the BGP 
spec in support of the text that I had provided, citing specific 
parts of the spec as a suitable basis for the security requirements. 
In response, on 1/6/05 Russ sent a message that ended with the 
comment:

You can point out all sorts of phrases and comments in the draft, but 
you have to temper these statements with the actual operation of BGP 
in the real world, with real address ownership concepts, real 
aggregation, and real route origination policies.

This sounds like a statement that Russ does not feel that the BGP 
spec provides a suitable basis for developing the security 
requirements.

I another message on 1/6/05 Russ also said:

And at some point, the WG has to decide which of these two models is 
valid. I believe that I've made a strong case to consider the 
operational use as a valid model, because of gaps in the alternative 
model.

Russ was commenting on the following text in my message:

>We both have prejudices in approaching this problem.  One can fairly 
>say that I used the BGP spec as the basis for developing the 
>security requirements model that we then addressed with S-BGP. 
>Likewise, you adopted an operations-oriented view of security when 
>you developed soBGP. That does not make either approach 
>intrinsically valid or invalid.

I think this is a pretty clear statement by Russ that he believes 
that an operational model, rather than the BGP spec, is the right 
basis for the requirements.

In another message later that day, Russ reiterated this notion saying:

Regardless of your attempts at striking at me personally, Steve, I 
don't see how you can get around building a set of requirements based 
on what exists, rather than the BGP specification, which is only part 
of the way things really work.

The phrase "rather than the BGP specification" again seems to 
indicate a fairly strong bias against using the BGP spec as the 
primary basis for the security requirements.

With regard to your question of whether BGP as deployed matches the 
spec, I note the following comment in a message from Iljitsch on 
1/6/05. We were discussing what forms of aggregation are permitted by 
the BGP spec and he said:

Now all of this non-RFC-compliant aggregation works without any 
problems because of the longest match first rule.

This is a pretty direct statement calling into question congruence 
between the BGP spec and operational practice.

Finally, you close with "This document is intended to present a set 
of requirements from the operator community to the folks creating the 
standards ..."  I have to admit that I do not recall hearing that 
characterization of the goal for this document. The WG charter does 
not convey the notion that this document is to represent the operator 
view of security requirements for BGP. Your description of the 
context for developing the document is consistent with the concerns I 
expressed, i.e., an operational vs. protocol spec based perspective.

I'd like to hear from both WG chairs with regard to whether the 
document is supposed to have this orientation, i.e., that it is 
supposed to be an operationally-oriented view of security 
requirements for BGP. If the context is what you suggest, I think my 
question to the IESG seems very much relevant. The WG charter makes 
no mention of an operational bias in developing routing security 
requirements.

Steve

---

From: Russ White <[email-masked]>
Date: Fri, 21 Jan 2005 11:44:18 -0500 (Eastern Standard Time)

> What said is that we are at an impasse re what to use as a basis for the 
> requirements. I say this based on the extended discussions on the list 
> with Russ, in which he said, repeatedly, that using the BGP spec as the 
> primary basis for the requirements document is inappropriate.

Let me clarify this a bit. When I say I don't believe the BGP specification 
is a good place to start, what I mean, specifically, is that the processes 
described in the BGP specification are not what we should be trying to 
secure.

Attempting to secure the processes used to transmit and receive updates is 
the incorrect basis for a requirements draft. We should be asking questions 
about the data, and how it matches the real world, based on multiple 
sources, and not just the BGP specification.

Attempting to secure the process of sending, receiving, and processing an 
update, as in saying: "A speaker should be able to verify that an update 
has actually passed through the AS' listed in the as path," is meaningless 
in the context of BGP, for various reasons. Stating: "A BGP speaker should 
be able to verify the path described in the as path of a received route," 
is meaningful.

I don't care where the update came from, in terms of accuracy of data. I 
might care in terms of non-repudiation, but the questions should be 
separated--accuracy of data vs non-repudiation.

I think the primary point of the argument is that I don't want to secure 
the processes used in BGP, I want to secure the data carried in BGP. In 
that context, we must take into consideration such things as authorization 
to advertise a set of addresses (which everyone agrees is a critical 
component of any security architecture, and yet is plainly not covered 
anyplace in the BGP specifications), deployability, and other factors.

I would argue that since the final recommendation will impact the work of 
the IDR working group directly, the most appropriate place for the 
requirements to be defined is in the routing area. We specifically started 
the RPsec WG as an area where routing, operations, and security folks could 
mix and talk, so we consciously intended the result of having multiple 
inputs into the requirements documents.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: "Bora Akyol" <[email-masked]>
Date: Fri, 21 Jan 2005 08:50:25 -0800

Jeff

Whether it is certifiably "secure" or not, a lot of operators
already use out of band information to secure
inter-domain routing.

Routing registries, Cymru are two examples of 
information databases that __are__ offline that are used.
 
We can argue until we turn blue in the face about
which one is better, but I think people would like to start
with something that is easily deployable and buys them
__some__ security.

The fact that at least one of the solutions has been around
for at least 7 years and has not seen large scale deployment (if any),
I think tells volumes about what the operator community want.

Although IETF is not an operator forum, I think it is in the spirit
of the IETF (of years past possibly) to listen to what people want.

Security is not a 1 bit decision as you and I discussed many times
before, it is a real number scale between 0 and 1. And there is no
reason why we can not start at (say) 0.65 and work our way up.

Regards,

Bor

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jeffrey Haas
> Sent: Friday, January 21, 2005 7:08 AM
> To: Tony Tauber
> Cc: [email-masked]
> Subject: Re: [RPSEC] proposed message to the IESG
> 
> Tony,
> 
> I agree that securing inter-domain routing is a good goal.  
> That goal says more than securing BGP, particularly in the 
> sense that we care about securing operational practices 
> beyond just the security of the
> BGP-4 protocol.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Jan 2005 11:55:22 -0500

Bora,

> information databases that __are__ offline that are used.

Please keep in mind that I was one of the final operators of RSng.
I've worked on the IRRd code and helped administer the RADB.  So,
you're preaching to the choir. :-)

I'm only saying "don't throw the baby out with the bath water"
or in this case, "let's not get into a situation where the answer
is throwing out BGP".  Nothing more.

-- 
Jeff Haas 
NextHop Technologies

---

From: Blaine Christian <[email-masked]>
Date: Fri, 21 Jan 2005 12:02:03 -0500

Hey Steve,

I suppose when you have an operator as editor you will get a bit of operator
slant <grin>.   One perspective might be that, in most venues,  the
potential customers of a service usually drive the requirements.  We do have
protocol developers on this thread and writing for the draft itself.  My
perception is that the value I add to the process is giving people a
perspective on what operators would find deployable.

I will try to go back through and find your text recommendations.  I was
hoping to apply the consensual view to the document.  When vigorous debate
ensued I decided to wait and see if we could come to terms.

I know it is asking a lot...  But if we could approach this in small chunks
maybe we can address specific concerns point by point.  My thought is that
we should encompass the needs of the BGP spec in a way that addresses the
manner in which things were actually deployed (if that makes any sense).

Regards,

Blaine

On 1/21/05 10:54 AM, "Stephen Kent" <[email-masked]> wrote:

> I did no say that the current draft of the security requirements document does
> not follow the BGP spec. I will send a separate message addressing that issue,
> later.
> 
> requirements. I say this based on the extended discussions on the list with
> Russ, in which he said, repeatedly, that using the BGP spec as the primary
> basis for the requirements document is inappropriate.
> 
> Russ began making these comments in late December, when I responded to his
> comments on the current draft. (In fact, I never managed to get around to
> commenting on the draft itself, because of all the time spent arguing wit Russ
> over his and my suggested changes!) I proposed text in a message on 12/28/04
> that I thought was appropriate for the draft, and I explained why, i.e.,
> because it was traceable to the BGP spec. That triggered an intense discussion
> on the list (between Russ and me) that lasted for over a week.
> 
> If we agree that the BGP spec is the starting point for security requirements,
> then we have an objective basis for deciding whether proposed text is
> appropriate or not. That is why I have pursued this issue.
> 
> On 1/5 I sent a message that contained a lot of excerpts from the BGP spec in
> support of the text that I had provided, citing specific parts of the spec as
> a suitable basis for the security requirements. In response, on 1/6/05 Russ
> sent a message that ended with the comment:
> 
> You can point out all sorts of phrases and comments in the draft, but you have
> to temper these statements with the actual operation of BGP in the real world,
> with real address ownership concepts, real aggregation, and real route
> origination policies.
> 
> This sounds like a statement that Russ does not feel that the BGP spec
> provides a suitable basis for developing the security requirements.
> 
> And at some point, the WG has to decide which of these two models is valid. I
> believe that I've made a strong case to consider the operational use as a
> valid model, because of gaps in the alternative model.
> 
>> We both have prejudices in approaching this problem.  One can fairly say that
>> I used the BGP spec as the basis for developing the security requirements
>> model that we then addressed with S-BGP. Likewise, you adopted an
>> operations-oriented view of security when you developed soBGP. That does not
>> make either approach intrinsically valid or invalid.
> 
> I think this is a pretty clear statement by Russ that he believes that an
> operational model, rather than the BGP spec, is the right basis for the
> requirements.
> 
> Regardless of your attempts at striking at me personally, Steve, I don't see
> how you can get around building a set of requirements based on what exists,
> rather than the BGP specification, which is only part of the way things really
> work.
> 
> The phrase "rather than the BGP specification" again seems to indicate a
> fairly strong bias against using the BGP spec as the primary basis for the
> security requirements.
> 
> 
> With regard to your question of whether BGP as deployed matches the spec, I
> note the following comment in a message from Iljitsch on 1/6/05. We were
> discussing what forms of aggregation are permitted by the BGP spec and he
> said:
> 
> Now all of this non-RFC-compliant aggregation works without any problems
> because of the longest match first rule.
> 
> This is a pretty direct statement calling into question congruence between the
> BGP spec and operational practice.
> 
> Finally, you close with "This document is intended to present a set of
> requirements from the operator community to the folks creating the standards
> ..."  I have to admit that I do not recall hearing that characterization of
> the goal for this document. The WG charter does not convey the notion that
> this document is to represent the operator view of security requirements for
> BGP. Your description of the context for developing the document is consistent
> with the concerns I expressed, i.e., an operational vs. protocol spec based
> perspective.
> 
> I'd like to hear from both WG chairs with regard to whether the document is
> supposed to have this orientation, i.e., that it is supposed to be an
> operationally-oriented view of security requirements for BGP. If the context
> is what you suggest, I think my question to the IESG seems very much relevant.
> The WG charter makes no mention of an operational bias in developing routing
> security requirements.
> 
> Steve
>

---

From: [email-masked]
Date: Fri, 21 Jan 2005 18:43:55 +0100

> view of security requirements for BGP.

I don't see a need for the document to represent *only* the operator
view of security requirements for BGP. However, if the operator view
is not represented at all, there is a high probability that anything
based on this document would be ignored by many operators.

Working for an operator myself, I clearly feel that if there is a
conflict between the BGP spec and the way BGP is actually used by a
significant number of operators, the operational practices need to be
taken into consideration - and the conflict should be explicitly
spelled out.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jan 2005 17:14:05 -0500

At 11:44 AM -0500 1/21/05, Russ White wrote:
>>What said is that we are at an impasse re what to use as a basis 
>>for the requirements. I say this based on the extended discussions 
>>on the list with Russ, in which he said, repeatedly, that using the 
>>BGP spec as the primary basis for the requirements document is 
>>inappropriate.
>
>Let me clarify this a bit. When I say I don't believe the BGP 
>specification is a good place to start, what I mean, specifically, 
>is that the processes described in the BGP specification are not 
>what we should be trying to secure.

What you keep saying is that you don't want to use the BGP specs as a 
basis for determining security requirements because you prefer to not 
focus on securing the process but rather the outcome of the process. 
The problem with this approach is that the specs do not provide a 
description of the outcome. So, the WG gets into arguments about what 
the outcome should be, with no objective basis for deciding what is 
or is not correct.  That's why I believe that we need to base the 
security requirements on the algorithmic aspects of the spec.

yes, we all agree that there are some aspects of the requirements 
that will be outside the scope of the BGP spec, but we have not yet 
managed to get a clean description of which parts fit where, because 
you reject the notion of the protocol spec as the primary basis for 
the security requirements.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jan 2005 16:53:51 -0500

At 12:02 PM -0500 1/21/05, Blaine Christian wrote:
>Hey Steve,
>
>I suppose when you have an operator as editor you will get a bit of 
>operator slant <grin>.   One perspective might be that, in most 
>venues,  the potential customers of a service usually drive the 
>requirements.  We do have protocol developers on this thread and 
>writing for the draft itself.  My perception is that the value I add 
>to the process is giving people a perspective on what operators 
>would find deployable.

We all bring our own perspectives to the table.  The WG co-chairs 
chose you to be the lead editor and thus one could say that they 
implicitly endorsed the idea of bringing an operations slant to the 
document. However, the WG charter does not state that, and the home 
for the WG is not the operations area.  That, in part, is why I 
suggested two weeks ago to bring this issue to the IESG.

>I will try to go back through and find your text recommendations.  I 
>was hoping to apply the consensual view to the document.  When 
>vigorous debate ensued I decided to wait and see if we could come to 
>terms.

I'll get back to you with specific suggestions relative to the 
original text (vs. the comments I made relative to the suggestions 
Russ, made).

>I know it is asking a lot...  But if we could approach this in small 
>chunks maybe we can address specific concerns point by point.  My 
>thought is that we should encompass the needs of the BGP spec in a 
>way that addresses the manner in which things were actually deployed 
>(if that makes any sense).

Working on this a chunk at a time makes sense to me too.

My problem with the "the way things are actually deployed" aspect of 
this is that it puts all of us non-operations folks at a disadvantage 
in the discussion. The BGP spec is readily available to all of us, 
and it represents an IETF approved document. How BGP is deployed and 
how ISPs make use of it is not documented in the same fashion, seems 
subject to more interpretation, and thus represents a more 
contentious basis for our discussions.

Steve

---

From: Russ White <[email-masked]>
Date: Fri, 21 Jan 2005 17:29:56 -0500 (Eastern Standard Time)

See my email to Sandy. I think I've explained myself enough times on list, 
and I don't see how this email contributes to the conversation. I've not 
seen a single refutation of any reason I've given for my position, other 
than a continuing statement: "We should base the requirements on the 
algorithms in the BGP specification" repeated over and over again.

:-)

Russ

On Fri, 21 Jan 2005, Stephen Kent wrote:

> What you keep saying is that you don't want to use the BGP specs as a basis 
> for determining security requirements because you prefer to not focus on 
> securing the process but rather the outcome of the process. The problem with 
> this approach is that the specs do not provide a description of the outcome. 
> So, the WG gets into arguments about what the outcome should be, with no 
> objective basis for deciding what is or is not correct.  That's why I believe 
> that we need to base the security requirements on the algorithmic aspects of 
> the spec.
>
> yes, we all agree that there are some aspects of the requirements that will 
> be outside the scope of the BGP spec, but we have not yet managed to get a 
> clean description of which parts fit where, because you reject the notion of 
> the protocol spec as the primary basis for the security requirements.
>
> Steve
>