Subject: [RPSEC] BGP Security Requirements v08

From: Tony Tauber <[email-masked]>
Date: Mon, 9 Jul 2007 07:21:32 -0700

Hi Folks,

Here's the latest revision of the BGP Security Requirements I-D
incorporating comments recieved:

http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-08.txt

Diff from last version:

http://tools.ietf.org/wg/rpsec/draft-ietf-rpsec-bgpsecrec/draft-ietf-rpsec-bgpsecrec-08-from-07.wdiff.html

Please send your feedback.

Thanks,

Tony

----- Forwarded message from [email-masked] -----

From: [email-masked]
Date: Sun, 08 Jul 2007 18:15:02 -0400
To: [email-masked]
Cc: [email-masked]
Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-08.txt 

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF.

	Title		: BGP Security Requirements
	Author(s)	: B. Christian, T. Tauber
	Filename	: draft-ietf-rpsec-bgpsecrec-08.txt
	Pages		: 19
	Date		: 2007-7-8
	
The security of BGP, the Border Gateway Protocol, is critical to the
   proper operation of large-scale internetworks, both public and
   private.  While securing the information transmitted between two BGP
   speakers is a relatively easy technical matter, securing BGP, as a
   routing system, is more complex.  This document describes a set of
   requirements for securing BGP, including communications between BGP
   speakers, and the routing information carried within BGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-08.txt

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Jul 2007 11:38:44 -0400

Tony,

Thanks for updating the requirements document. I see that almost all 
of my suggested edits were incorporated, but a couple of questions I 
raised in my comments were not addressed, which leaves some 
ambiguity.  Here are the residual questions/comments:

In (new) section 4.2 (Incremental Deployment), the second bullet says:

o  A BGP security mechanism MUST provide backward compatibility in 
the message formatting, transmission, and processing of routing 
information carried through a mixed security environment.  Message 
formatting in a fully secured environment MAY be handled in a 
non-backward compatible fashion though care must be taken to ensure 
UPDATES can traverse intermediate routers which don't support the new 
format.

My comment was:  One might interpret this to mean that any extended 
form of UDATE message MUST be transmitted through ASes that are not 
capable of processing it. This is imposing an unnecessary burden on 
solutions, since an
alternative is to just mot send such messages through ASes than can't 
make use of them.

I'd like to see a clarification of the intent of this bullet, 
relative to the concern I raised in my comment.

The next bullet in the section says:

In an environment where both secured and non-secured systems are 
interoperating a mechanism MUST exist for secured systems to identify 
whether an originator intended the information to be secured.

My questions was: Does this refer to the Origin AS or the neighbor AS?

I still think we need to say to which originator this bullet refers.

Finally, the last paragraph of (new) section 8 says:

An associated delegation criteria is the requirement to allow for 
non-BGP stub networks.  As a result, all secured BGP implementations 
MUST allow for the contemporaneous origination of a route for a 
prefix by more than one AS.

I had suggested adding the phrase "subject to the authorization 
criteria above." at the end of the last sentence. I was wondering why 
you chose to not add this?

Steve

---

From: Tony Tauber <[email-masked]>
Date: Tue, 10 Jul 2007 14:35:38 -0700

Hi Steve,

As usual your detailed comments were helpful.
Comments are inline.

On Tue, Jul 10, 2007 at 11:38:44AM -0400, Stephen Kent wrote:
> solutions, since an alternative is to just mot send such messages
> through ASes than can't make use of them.

I see this requirement as a (possibly unnecessary) corollary to the
requirement for supporting non-contiguous deployments.  The fact that
the interpretation is ambiguous about how specifically one achieves this
goal (perhaps properly) reflects the fact that solutions can get
creative.  

I'd like to hear whether others find this item problematic.

> I still think we need to say to which originator this bullet refers.

My reading of it would be "originator".  I didn't find it ambiguous.

Perhaps you or someone else could suggest clearer text if needed.

> you chose to not add this?

It was a simple oversight.  I can put it in.

Thanks,

Tony

---

From: [email-masked] (Sandy Murphy)
Date: Tue, 10 Jul 2007 17:44:30 -0400 (EDT)

> through ASes than can't make use of them.

This is a question about use of security information during initial
deployment.  If there are islands of deployment that must communicate
through seas of non-deployment, is it useful for the deployer to
learn that there is a protected route island out there?  When the
information came to them over an unprotected sea?

I'd say that there is a potential for benefit.  Perhaps the unprotected
sea in between is known by other out-of-band means to be reliable,
even if clueless about the new protection mechanisms.  There might
be operational procedures that protect the intermediate sea that
are adequate from the point of view of the recipient on the island.

So I'd say that passing the info along is potentially beneficial,
to some, and should be passed.  The cost to the clueless routers
is storage and bandwidth - processing cost should be minimal.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Jul 2007 18:04:13 -0400

>goal (perhaps properly) reflects the fact that solutions can get

I worried that one might interpret the requirement as imposing an 
undue restriction on solutions, by requiring that solutions be able 
to send UPDATEs with a modified format through ASes that might not be 
able to process a new format. We seem to be in agreement that one 
ought not impose such requirements on solutions. If so, then how 
about rewording this bullet to say:

"A BGP security mechanism MUST provide backward compatibility in
the message formatting, transmission, and processing of routing
information carried through a mixed security environment.  Message
formatting in a fully secured environment MAY be handled in a
non-backward compatible fashion. Care must be taken to ensure either that
UPDATES can traverse intermediate routers which don't support the new
format, or that UPDATEs using a new format are not sent to ASes that cannot
support such messages."

>...

To avoid ambiguity I would suggest:

"In an environment where both secured and non-secured systems are
interoperating a mechanism MUST exist for secured systems to identify
whether the origin AS for a route intended the routing information 
being transmitted to be secured."

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Jul 2007 18:27:24 -0400

>is storage and bandwidth - processing cost should be minimal.

Sandy,

You make a good point about the potential benefits of being able to 
pass updated UPDATEs through ASes who are not able to make use of 
them. However, the benefit is only a potential one, and the flip side 
is that the intermediate ASes might not be able to store the data 
from the UPDATEs, which would thus disallow the solution approach. 
If, as Tony suggested, we want to avoid imposing undue constraints on 
solutions, then we ought not impose this specific one.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 11 Jul 2007 09:33:50 -0400

> format, or that UPDATEs using a new format are not sent to ASes that cannot

This is a pretty traditional and standard argument in routing protocol
circles whenever extensions to a routing protocol are proposed--do we
make it so older routers can at least forward the new information, or do
we make it so it won't work in the presence of older routers? IMHO, it
generally comes down to--is the information useful to routers on the
other side of the nonsupporting router?

Maybe it's useful to break this into two questions?

1. Is information about the authorization of an originator to advertise
reachability useful to AS' on the "other side" of a non-supporting AS?

2. Is information about the validity of an AS path useful to AS' on the
"other side" of a non-supporting AS?

If we could resolve these two questions, I think the wording pretty much
falls out (?)....

:-)

Russ

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

---

From: Russ White <[email-masked]>
Date: Wed, 11 Jul 2007 09:37:19 -0400

In a separate email, and with my WG chair hat _off_....

> "other side" of a non-supporting AS?

IMHO, as an individual, I believe both of these pieces of information
are useful. I believe the origin authorization information is really
useful, along with the first hop (or second hop, depending on your point
of view) of the AS Path. The subsequent hops of the AS path are less
interesting than these two to the receiver on the "other side" of a
non-supporting AS.

Why? Because if you can validate the originator and the first (second)
hop (the second entry in the AS Path), then you have a good bit more
assurance the destination is valid/etc, than if you just drop this
information out.

:-)

Russ

- --

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Jul 2007 06:42:11 -0700

> Please send your feedback.

I didn't see any changes related to the feedback I posted on the
transport protocol issues and GTSM. There are a number of current I-Ds
in this space that are not discussed, and any description that includes
the need for keying (SHOULD) might reconsider whether GTSM qualifies as
relevant at all in this space.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

---

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Wed, 11 Jul 2007 07:06:44 -0700

> I didn't see any changes related to the feedback I posted on 
> the transport protocol issues and GTSM. There are a number of 
> current I-Ds in this space that are not discussed, and any 
> description that includes the need for keying (SHOULD) might 
> reconsider whether GTSM qualifies as relevant at all in this space.

I see a tool - GTSM - that allows me to policy check the packet in
the forwarding ASIC - before I punt to the control plane of the
device - as totally relevant. It is a working tool which add
resistance to DOS.

---

From: Tony Tauber <[email-masked]>
Date: Wed, 11 Jul 2007 07:20:15 -0700

> relevant at all in this space.

Hi Joe,

I appreciate your comments and attention.  I tried to work these in with
by making a couple of modest changes in what's now section 11.  GTSM is
(and was) only mentioned in the doc by way of saying it's inadequate as
a "solution".  If you feel strongly that more change is needed, send
proposed text.

Thanks,

Tony

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Jul 2007 07:28:46 -0700

Hi, Tony,

I'd be glad to send text, since that might be a useful way forward.

Thanks!

Joe

---

From: [email-masked] (Sandy Murphy)
Date: Wed, 11 Jul 2007 10:32:19 -0400 (EDT)

>assurance the destination is valid/etc, than if you just drop this

As many people have said (I recall particularly Danny McPherson at NANOG),
a deliberate attack would just take the valid initial info and add
invalid info to it.  So it is best to be cautious about the good bit
more assurance.

--Sandy

---

From: Russ White <[email-masked]>
Date: Wed, 11 Jul 2007 10:45:36 -0400

> invalid info to it.  So it is best to be cautious about the good bit

Right--the more information you have, the more assurance you have. Just
the origination authorization is easy to fool. Including the second AS
in the AS Path (the first hop) makes it harder to fool but still not
impossible. As you add more path information, you add more assurance.

So, I would say it's not an "all or nothing" affair, and retaining
information through a non-supporting AS is useful.

:-)

Russ

- --

---

From: [email-masked] (Sandy Murphy)
Date: Wed, 11 Jul 2007 10:49:08 -0400 (EDT)

>information through a non-supporting AS is useful.

I agree.  I already said that, but I just wanted to be sure my comment
about caution did not indicate I had changed my mind.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Jul 2007 11:04:17 -0400

At 9:33 AM -0400 7/11/07, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

I agree that it is generally useful to have a router forward data 
that it can't use itself, but that a later router might be able to 
use.  However, I am not comfortable with a suggestion that if a 
solution cannot always guarantee this capability, that it is an 
unacceptable solution.

>reachability useful to AS' on the "other side" of a non-supporting AS?

it could be useful.

>"other side" of a non-supporting AS?

because there may be no way to verify the number, much less the 
identify of ASes listed in an UPDATE between the end of the secured 
path and the current AS, the utility of the passing that data beyond 
the end of the secured part of the path is questionable.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Jul 2007 11:13:58 -0400

>information through a non-supporting AS is useful.

I think it's a matter of what you security goals are.

	- If you want assurance that the traffic you are forwarding 
will NOT go through a certain AS, then any gap in the secured path 
undermines this goal, irrespective of the number of "good" hops on 
the path you receive.

	- If you assurance that the path you receive is one that will 
likely cause your traffic to be delivered, again the number of "good" 
hops on the path you receive is irrelevant, as an attacker could grab 
a valid long or short path and add themselves onto it.

So I'm not sure that one can generalize about the increased assurance 
afforded by a path with more hops that can be verified as accurate.

Also, I worry that it is asking a lot for an operator to try to take 
a mix of unauthenticated paths, authenticated paths, and partially 
authenticated paths and decide how to weight them in making a route 
selection. We have a fair number of examples in other areas where 
adding this sort of complexity leads to more config errors with 
adverse security implications.

Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Jul 2007 00:05:35 -0400

> a "solution".  If you feel strongly that more change is needed, send

GTSM is very effective in protecting against certain high volume
attacks that would cripple infrastructure protected by cryptographic
means alone.  From a practical standpoint GTSM used alone may be
inadequate as a solution (though some ISPs might contest even that)
but it is a required part of any solution in an ISP environment.

Curtis

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Jul 2007 23:57:14 -0700

Curtis Villamizar wrote:
...
> but it is a required part of any solution in an ISP environment.

I agree that DOS attacks benefit from protections that help reduce the
impact of attack traffic; GTSM falls into that category - it's clearly a
useful part of a DOS solution, but DOS protection isn't cryptographic
protection. The bulk of the BGP security requirements document focuses
on cryptographic issues - not DOS protection. It's worth noting the
difference, but not lumping the solutions together.

Joe

---

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Fri, 13 Jul 2007 07:40:07 -0700

In the last draft it was pretty clear.  

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Thursday, July 12, 2007 11:57 PM
> To: [email-masked]
> Cc: [email-masked]; Tony Tauber
> Subject: Re: [RPSEC] BGP Security Requirements v08
> 
> 
> 
> Curtis Villamizar wrote:
> ...
> > inadequate as a solution (though some ISPs might contest even
> > that)  but it is a required part of any solution in an ISP
> > environment.  
> > 
> > Curtis
> 
> I agree that DOS attacks benefit from protections that help 
> reduce the impact of attack traffic; GTSM falls into that 
> category - it's clearly a useful part of a DOS solution, but 
> DOS protection isn't cryptographic protection. The bulk of 
> the BGP security requirements document focuses on 
> cryptographic issues - not DOS protection. It's worth noting 
> the difference, but not lumping the solutions together.
> 
> Joe
> 
> --

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Jul 2007 07:42:02 -0700

I disagree, and have offered to contribute text already.

Joe

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Jul 2007 12:32:01 -0400

In message <[email-masked]>
Joe Touch writes:
> =2E..
> >=20

Joe,

It would be most accurate most helpful to acknowledge the strengths
and weaknesses of both and then define the limit of scope of your
work.  Cryptographic solutions can provide for protection over an
insecure channel but cannot provide protection against very high
traffic volume DOS attacks.  GTSM protects against very high traffic
volume DOS attacks over a secure channel to a peer but provides no
protection over an insecure channel.  Which approach is appropriate,
or both, depends on the situation.  The scope of your work is
cryptographic solutions.  (Some ISPs have noted that this does not fit
*their* problem space, but it does fit other problem spaces).

So we seem to be in violent agreement about the difference between
crypto solutions and DOS solutions.  Its just a matter of the wording
in the draft not adequately acknowledging the part of the problem
space that is not addressed.

draft-behringer-bgp-session-sec-req-01.txt cites rfc4593 which defines
part of the real world problem.  ISPs might argue that rfc4593 is
silly in the context of a fiber strung across 20 feet of collocation
space that is regularly taken down by DOS attacks and they'd be right.
Its time these security requirements documents acknowledged that.

For the ISP, GTSM protects the BGP peerings.  Packet filtering
protects the IGP if its OSPF (not applicable for ISIS).  Crypto
protection of the session can protect against low traffic volume
internal attacks.  Other applications such as routing in a wireless
battlefield would have different requirements.  We don't need to go
into specifics but both types of attack need to be acknowledged.
Drafts/RFCs describing requirements need to be clear about this and
specify which problem space they are addressing without implicitly
denying that the other problem space exists.

The way the draft reads now is GTSM, TCP/MD5, etc are all "prior work"
and the reader might interpret this to mean that work meeting these
BGP requirements supercede that prior work.  It doesn't state
otherwise and it should.

Curtis

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Jul 2007 09:39:37 -0700

Curtis Villamizar wrote:
> work. 

Agreed...

> space that is not addressed.

Agreed!

...
> BGP requirements supercede that prior work.  It doesn't state

Yes - that's the sort of thing I'm hoping to address in a brief paragraph.

Joe

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Jul 2007 12:47:02 -0400

In message <[email-masked]>
> In the last draft it was pretty clear.  

Are we reading the same draft?  It would be nice to have the draft
name in the subject line.

In draft-ietf-rpsec-bgpsecrec-08 the only mention of GTSM is the
following and there is no mention of the issue of high volume DOS.

   Current
   approaches to improving resilience of BGP transport (e.g., TCP-MD5
   [5] and GTSM [7]) are inadequate and require significant operator
   interaction to maintain a respectable level of security.

The draft is in denial regarding the existance of DOS issues, the
existing means to address DOS, and the fact that DOS is not addressed
by crypto methods.

I keep bringing this up and nothing changes.

Curtis

---

From: [email-masked] (Sandy Murphy)
Date: Fri, 13 Jul 2007 13:20:14 -0400 (EDT)

>Yes - that's the sort of thing I'm hoping to address in a brief paragraph.

I *think* Curtis meant the behring draft, not the bgpsecrec draft.

--Sandy

---

From: [email-masked] (Sandy Murphy)
Date: Fri, 13 Jul 2007 15:16:25 -0400 (EDT)

>crypto solutions and DOS solutions.
>...
>draft-behringer-bgp-session-sec-req-01.txt cites rfc4593

There is also Pekka Savola's draft, draft-savola-rtgwg-backbone-attacks-03.txt
which talks about the various attacks on routing infrastructure in
ISP backbones, the various countermeasures, and speaks briefly
about where each type of countermeasure would be appropriate.

He talked about this work at several working groups in Jul 06,
including rpsec.  The presentations seemed to be generally well
received, and there was some discussion of where the work would
best be done.  But no wg seems to have picked it up as a wg item.

Should there be discussion of picking up both the behringer and
the savola drafts as wg items?

(Actually, the routing ADs may know more about the status of
the savola draft, so I've put them on the recipient list.)

--Sandy

---

From: Russ White <[email-masked]>
Date: Fri, 13 Jul 2007 16:48:05 -0400

> the savola drafts as wg items?

I think so.... I wonder how this overlaps with the p-2-p bgp draft also
being considered? Or wasn't there one? What happened to that one?

:-)

Russ

- --

---

From: [email-masked] (Sandy Murphy)
Date: Fri, 13 Jul 2007 16:49:32 -0400 (EDT)

>being considered?

I don't quite know what you mean by a p-2-p bgp draft.  The behringer
draft concerns the security requirements of protecting the bgp peer to
bgp peer connection (e.g., TCP MD5).  Perhaps that is what you are
talking about?

http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-01.txt

Abstract

   The document "BGP security requirements"
   (draft-ietf-rpsec-bgpsecrec-07) specifies general security
   requirements for BGP.  However, specific security requirements for
   single BGP sessions, i.e., the connection between two BGP peers, are
   only touched on briefly in the section "transport layer protection".
   This document expands on this particular aspect of BGP security,
   defining the security requirements between two BGP peers.

--Sandy

---

From: Russ White <[email-masked]>
Date: Fri, 13 Jul 2007 17:57:05 -0400

>    defining the security requirements between two BGP peers.

Yes... We should pick this work up as a WG item, I think, because it
really relates directly to the charter. But, I'll leave it to Tony to
bring it up at the Chicago meeting (it overlaps with Networkers this
time, and I really can't skip Networkers, *sigh*.

We should try and see what folks think on list before then, if possible,
though, I think (?).

:-)

Russ

- --

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Jul 2007 21:26:58 -0400

> solution cannot always guarantee this capability, that it is an 

I think most of the WG is comfortable with this and is insisting on
it.  How many times do we need to go in circles on this?  Once every
IETF meeting?

> >reachability useful to AS' on the "other side" of a non-supporting AS?

Yes.  So don't create a protocol that prevents it.

> the end of the secured part of the path is questionable.

The real world problem is that this is the best you are going to get
for attempts to use any such mechanism on most of the Internet at
least during early deployment which might be many years or longer.
There is no sense defining a protocol which won't get deployed.  If
you do there is a good chance it won't be widely implemented - or
implemented at all without someone throwing big money at it.  So even
if the application you have in mind would never trust information from
another island, you need this capability to have some chance that the
protocol you define will get widely implemented and eventually
deployed in enough places to start to gather critical mass.

A bit of optimism maybe.

Curtis

---

From: "Michael H. Behringer" <[email-masked]>
Date: Mon, 16 Jul 2007 18:33:30 +0200

[Just back from vacation today, so I missed the earlier discussion.]

Just as a reminder where I was coming from with my draft http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-01.txt: This was directly taken from a to-do-list from Russ, specifying that the WG needs to work on the point-to-point security requirements of BGP speakers:

At 15:37 06/01/2007, Russ White wrote:
[...]
>o P-2-P security requirements for BGP: This was to provide some cover
>and thinking on the various TCP auth mechanisms to replace MD5 that are
>currently being considered. We need, I believe, a volunteer to
>author/edit this, and get it moving.
[...]

I request (again) that my draft be accepted as a WG item, after all it's taken from the WG's to-do list ;-) 
 
The problem space of draft-behringer-bgp-session-sec-req-01 is significantly smaller than that of draft-ietf-rpsec-bgpsecrec-08; I can see this work remaining independent, but I can also see it merged with draft-ietf-rpsec-bgpsecrec-08. My current preference is to keep it standalone, since it's problem space is nicely small and well-defined. But I have no strong views either way. I guess we should discuss this in Chicago. 

BTW, I have received a number of emails with feedback which I have not yet incorporated into the draft, due to time constraints. Apologies for that. Will happen after the IETF. 

See you all next week, 
Michael

At 23:57 13/07/2007, Russ White wrote:
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.6 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQFGl/UxER27sUhU9OQRAhb4AKDJRU5Emu0HvOTK4IZ1qxQoAk62DgCeKP1P
>vlNLckQ+M00dNx/MrSsDboo=
>=/PTq
>-----END PGP SIGNATURE-----
>
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Jul 2007 14:28:54 -0400

>it.  How many times do we need to go in circles on this?  Once every

You may be right. Hoqwever, I appear to be the primary (only?) person 
who reads each draft and provides comments and edits to Tony, so I'm 
don't think that the WG consensus has been established, at least not 
through the editing process.

>deployed in enough places to start to gather critical mass.

Sorry, Curtis, but I don't understand your reasoning above.

I think we all want to establish requirements for a protocol that 
will be widely deployed, and agree that deployment will be a long 
time coming.

I think the question is why, if the path info received by an "island 
AS" has a number of unverified hops, is this path info useful, in a 
security sense, to the AS that receives? How does the requirement to 
send such info promote adoption of the protocol?

Steve

---

From: Robert Loomans <[email-masked]>
Date: Tue, 17 Jul 2007 12:18:55 +1000

> it.  How many times do we need to go in circles on this?  Once every

Curtis, Stephen, please correct me if I'm mis-characterising your
opinions...

Curtis, you seem to be saying that passing on the information via
non-supporting routers is better than nothing, and so should definitely
be done.

Stephen, you appear to be saying that it might be found to be pointless
or, in fact, worse than useless (ie, actively harmful), and don't want
to be committed to doing so this early in the game.

Is that correct?

Rob

-- 
Robert Loomans                                 Email:  [email-masked]
Senior Programmer/Analyst, APNIC               Phone:    +61 7 3858 3100
http://www.apnic.net                             Fax:    +61 7 3858 3199

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jul 2007 09:57:14 -0400

>to be committed to doing so this early in the game.

Rob,

yes, that's a good, concise characterization of my position.

Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 17 Jul 2007 10:26:19 -0400

> send such info promote adoption of the protocol?

Because it is likely to be more reliable than information with no
authentication at all.

The major ISPs are fairly reliable at getting their internal routing
right so if the non-authenticating routers in the middle are entirely
in a set of ISPs that are known to generally not have breakins into
their own infrastructure.  For the purposes of commercial traffic
among other ISPs that want to distinguish their services as having
somewhat more reliable routing due to the use of authentication, there
is a great deal of value.

It may be optimistic to think that this value would be enough to give
any routing authentication sufficient value to gain critical mass in
the commercial world.  If there is no value for islands of deployment
except to authenticate within the island this is a non-starter from
day one in the commercial world.  If so it may be a non-starter at
router vendors without a very large influx of money from elsewhere,
such as government funding specifically for something that is not
being implemented because it will never get commercially deployed.  If
you are sure that the money is out there waiting for this spec to
publish, then fine.  Otherwise you may be wasting your time and ours
if the requirement to add value to disconnected islands is ignored.

That's just an opinion and I don't know how widely held it is today.
This might be a good question to ask at the WG meeting.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 17 Jul 2007 11:00:43 -0400

In message <[email-masked]>
"Michael H. Behringer" writes:
> Just as a reminder where I was coming from with my draft
> http://www.ietf.org/internet-drafts/draft-behringer-bgp-session-sec-req-01.txt:
> This was directly taken from a to-do-list from Russ, specifying that
> the WG needs to work on the point-to-point security requirements of
> BGP speakers:
>  

IMO this should be a WG item.

> The problem space of draft-behringer-bgp-session-sec-req-01 is
> significantly smaller than that of draft-ietf-rpsec-bgpsecrec-08; I
> can see this work remaining independent, but I can also see it merged
> with draft-ietf-rpsec-bgpsecrec-08. My current preference is to keep
> it standalone, since it's problem space is nicely small and
> well-defined. But I have no strong views either way. I guess we should
> discuss this in Chicago.

Since the requirements are those that the ISPs have been working from
for over a decade, it is likely that we will arrive at agreement on what
those requirements are within a reasonable amount of time.  Then
draft-ietf-rpsec-bgpsecrec can reference bgp-session-sec-req and we
can put to end any discussion on rpsec-bgpsecrec being incomplete due
to failure to acknowledge these requirements.

> BTW, I have received a number of emails with feedback which I have not
> yet incorporated into the draft, due to time constraints. Apologies
> for that. Will happen after the IETF.
>  
> See you all next week, 
> Michael

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jul 2007 11:09:48 -0400

>This might be a good question to ask at the WG meeting.

Curtis,

I think our difference of opinion arises from the different 
perspectives we bring to the problem.

As a "security guy" I would not agree with your opening statement. 
We usually worry that mixing unverified info with verified info, in 
any context, is a recipe for trouble, as it encourages folks to 
accept the mixed info and treat it as verified.  You give an example 
of ISPs wanting to " ... distinguish their services as having 
somewhat more reliable routing due to the use of authentication ..." 
That is precisely the sort of claim most security folks would worry 
about :-).

As for what will make incremental valuable enough to ISPs to warrant 
their buy-in, I think that's a hard call for anyone to make right 
now.  One possible deployment scenario is that the biggest ISPs will 
deploy first. If so, then the fact that most of these folks have 
direct peering arrangements with one another would allow them to 
benefit, irrespective of the issue of intermediaries who are not yet 
playing. If the next set of adopters are ISPs directly connected to 
the big ISPs, and often to one another (e.g., via IXPs), then they 
too can derive benefits in many instances, even without passing 
verified path info through unverified ASes.

So, given possible deployment scenarios like these, the uncertainty 
about which deployment scenarios may happen, and the security 
principle of avoiding situations that may encourage folks to accept 
mixed data as all authentic, I feel it's inappropriate to mandate 
support for passing such data along.

Steve

---

From: "James Ko" <[email-masked]>
Date: Tue, 17 Jul 2007 11:35:24 -0400

Indeed, ideally incoming data should be "authentic" and "verifiable",
otherwise we are back to square one and this work is no different but to
give bad guys a window of opportunity to run man-in-the-middle attacks,
or inject bogus routes.

James Ko, CISA CISM CISSP-ISSAP GCFW GCIH
OAM & Security 
Nortel
[email-masked]
phone 1 613 763 6920 (ESN 393 6920)

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 11:10 AM
To: [email-masked]
Cc: [email-masked]; Russ White
Subject: Re: [RPSEC] BGP Security Requirements v08

>their own infrastructure.  For the purposes of commercial traffic among

>other ISPs that want to distinguish their services as having somewhat 
>more reliable routing due to the use of authentication, there is a 
>great deal of value.
>
>except to authenticate within the island this is a non-starter from day

>one in the commercial world.  If so it may be a non-starter at router 
>vendors without a very large influx of money from elsewhere, such as 
>government funding specifically for something that is not being 
>implemented because it will never get commercially deployed.  If you 
>are sure that the money is out there waiting for this spec to publish, 
>then fine.  Otherwise you may be wasting your time and ours if the 
>requirement to add value to disconnected islands is ignored.
>

Curtis,

I think our difference of opinion arises from the different perspectives
we bring to the problem.

As a "security guy" I would not agree with your opening statement. 
We usually worry that mixing unverified info with verified info, in any
context, is a recipe for trouble, as it encourages folks to accept the
mixed info and treat it as verified.  You give an example of ISPs
wanting to " ... distinguish their services as having somewhat more
reliable routing due to the use of authentication ..." 
That is precisely the sort of claim most security folks would worry
about :-).

As for what will make incremental valuable enough to ISPs to warrant
their buy-in, I think that's a hard call for anyone to make right now.
One possible deployment scenario is that the biggest ISPs will deploy
first. If so, then the fact that most of these folks have direct peering
arrangements with one another would allow them to benefit, irrespective
of the issue of intermediaries who are not yet playing. If the next set
of adopters are ISPs directly connected to the big ISPs, and often to
one another (e.g., via IXPs), then they too can derive benefits in many
instances, even without passing verified path info through unverified
ASes.

So, given possible deployment scenarios like these, the uncertainty
about which deployment scenarios may happen, and the security principle
of avoiding situations that may encourage folks to accept mixed data as
all authentic, I feel it's inappropriate to mandate support for passing
such data along.

Steve

---

From: [email-masked] (Sandy Murphy)
Date: Tue, 17 Jul 2007 11:55:19 -0400 (EDT)

Curtis writes:
>their own infrastructure.

Curtis, I'm not sure exactly what you mean here, but Steve was talking
about AS hops, not router hops.  I *think* that's what you mean, also,
but I'm not sure.

Steve, I strongly believe that incremental deployment scenarios WILL
include cases where non-upgradable ASs will be provided with other,
operational or algorithmic, protections, so that ISPs in the know will
trust paths that come to them from those ASs.  I am less strongly
convinced that incremental deployment scenarios MUST include such cases.
But I see no way to provide benefit in incremental deployment otherwise.

I do not think that you are saying that solutions COULD NOT provide
benefit when island hopping.  The work being done in the sidr wg
(to provide an infrastructure that would provide authorization for
prefix origination) would be an example of protections that would
still provide benefit when island hopping, as the origin authorization
check is of value no matter how many clueless ASs touch the UPDATE.

I believe that you are arguing whether solutions should be REQUIRED
to provide benefit when island hopping.  And Curtis is arguing that
they should, because otherwise incremental deployment will be very
very unattractive.

The choices seem to boil down to MUST or SHOULD.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Jul 2007 12:19:00 -0400

>But I see no way to provide benefit in incremental deployment otherwise.

Incremental deployment in ASes that are adjacent to one another 
offers  advantages, and I think one cannot rule out scenarios in 
which adjacent ASes deploy an enhanced version of BGP.

>check is of value no matter how many clueless ASs touch the UPDATE.

True, the SIDR work will make origin AS authorization data available 
to every ISP by virtue of publishing ROAs. However, it does so 
without passing ROA data via BGP, so the non-adjacency issue does not 
apply in this case.

>The choices seem to boil down to MUST or SHOULD.

Or a MUST/SHOULD vs. MAY.

Steve

---

From: Tony Tauber <[email-masked]>
Date: Tue, 17 Jul 2007 09:32:43 -0700

What meaning a receiving AS might assign to a partially authenticated
piece of data is left up to that AS (keeping in the spirit of autonomy).

Certainly one can envision an attack which exposes the authenticated
origin info but which nefariously removes intervening hops to draw in
traffic improperly (e.g., to inspect, alter, or drop).

> Or a MUST/SHOULD vs. MAY.

Right, based on the discussion thus far, I was leaning toward keeping
the idea in as a MAY.  One might argue that doing so is effectively the
same as leaving it out altogether, but the intention and information is
retained.  Beyond that, asserting it as a "MAY" explicitly blocks any
interpretation which ends in "... NOT".

Tony

---

From: [email-masked] (Sandy Murphy)
Date: Tue, 17 Jul 2007 16:35:54 -0400 (EDT)

Tony Tauber said:

>the idea in as a MAY.

I am OK with that, especially the "keeping the idea in" part.

--Sandy

---

From: Russ White <[email-masked]>
Date: Wed, 18 Jul 2007 09:39:13 -0400

> interpretation which ends in "... NOT".

I would prefer SHOULD over MAY, because I believe there is value in
partially validated data.

:-)

Russ

- --

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Jul 2007 11:44:22 -0400

> That is precisely the sort of claim most security folks would worry 

As a security guy, you could think of it as a different kind of (not
very good) security across a known reliable ISP or a small set of
known reliable ISPs.  A provider may peer with one or more ISPs who
they know have excellent security practices and whose routing is known
to be fairly robust.  An set of AS with those AS numbers only plus
a set of authenticated AS would be more likely to deliver packets than
an AS Path through unauthenticated AS of unknown reliability.

What we are talking about here is prevention of DOS, not protection of
secrets.  Choosing a path that is extremely likely to be reliable but
not guarenteed to be reliable in practice is clearly an improvement
over choosing any available path.  It is the sole basis of most policy
routing decisions today.

My view on this is we can strive for perfection and get nothing at all
or try to improve the current situation and get the work implemented
with limited deployment in ISPs and due to being implemented the
security community has it and can use it as they please.  My concern
is that with no interest from ISPs it will be hard to get vendors to
implement and it will never get PS status for lack of implementation.

It would be nice to hear from ISPs since I'm not at one.  If memory
serves me, we had two opinions voiced.  One was that some sort of
transitive property across non-authenticated AS was a necessary
feature.  The other was that the storage overhead needed to be
reasonable or ISPs who did not use the authentication would simply
drop the attributes at their peerings.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Jul 2007 12:14:16 -0400

> give bad guys a window of opportunity to run man-in-the-middle attacks,

So why does Internet routing work at all today?  Rhetorical question.

It does work by the way.  Not always perfectly.

Curtis

ps - The answer is because the DOS would be short lived and very
traceable (ie: not much damage and they'd get caught).  The reason for
this is the bogus information would have to be injected from within an
ISP and ISP security of their own infrastructure is reasonably good.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Jul 2007 12:34:07 -0400

> about AS hops, not router hops.  I *think* that's what you mean, also,

What I meant is that 1) major ISPs do a very good job of filtering
customer routes and not originating bogus information into the global
BGP routing and 2) major ISP security is good enough that it is very
hard for an attacker to inject BGP information into an ISP from within
the ISP's own infrastructure.

That Internet routing for the most part works is partially due to the
above and that places where this is not true are enough AS hops away
from the major ISPs that bogus information is localized to those far
reaches that may be a little behind on the operations learning curve.

> The choices seem to boil down to MUST or SHOULD.

IMO if we are down to SHOULD and MUST:

  The protocol MUST support a mechanism ... [to connect islands, sic]

  The protocol MUST keep authentication information reasonable small.
  If that information needs to be large in order to be robust, then
  the protocol SHOULD provide an alternate smaller digest that is less
  likely to get tossed.

  ISPs SHOULD try to pass information to non-authenticating peers.

  ISPs SHOULD prefer information from a subset or trustworthy
  non-authenticating peer AS with partial authentication covering all
  less known AS over information where untrusted non-authenticating AS
  are in the path.

  Non-authenticating AS should pass the authentication information
  unchanged unless doing so is infeasible due to router memory
  constraints.

This needs rewording but I hope its clear enough for discussion.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Jul 2007 12:55:38 -0400

> traffic improperly (e.g., to inspect, alter, or drop).

You could imagine that but ...

The major ISPs have important major customers and peer.  For example
they would not want their routing corrupted by a bad route to a major
content provider.  Therefore many major providers will only accept
these major customer and peer routes from a very limited set of ISPs.

In order to get a short enough AS Path to have an effect on those
routes, you'd need to first break into the ISP infrastructure.

Then there are routes farther away.  For example, a few AS hops might
be required to reach a destination in Europe from the US.  If the AS
in between have both secure infrastructure and reasonable route policy
for any major European customer or peer the same situation exists.

This is why in theory a man-in-th-middle could inject bad information
but in practice it can't happen for most "important" routes (ones that
the ISPs consider most important because they are big paying customers
or having bad routes to them would be a significant disruption and
embarasement).

Add some authentication and you may have further improviment in the
reliability of routing information.  Don't allow that to cross the
major ISPs and the authenticaion is of very little use for ISPs.

A small ISP in the far reaches (less developed world, for example) may
get better connectivity and immunity from injection of bad routing
information for their own routes if they provide authenticaion on
routes they originate, register their routes for policy verification
by other ISPs, and check authentication and registration of routes
they receive.  The standard routing and security hygene also applies.

> interpretation which ends in "... NOT".

The MAY or SHOULD words MUST apply only to decisions regarding
deployment (MAY use some featured, SHOULD use some feature, MAY or
SHOULD pass some information ...).

In the requirements the word MUST has to be applied to protocol
definitions and protocol implementations or at the very least a SHOULD
with very strong emphasis.

Curtis

---

From: Russ White <[email-masked]>
Date: Wed, 18 Jul 2007 13:37:47 -0400

>   unchanged unless doing so is infeasible due to router memory

Maybe this would work?

The protocol SHOULD either either be designed so:

o Non-authenticating implementations will pass the authentication
information without modification.

o The authentication information may be passed between authenticating
implementations outside the BGP protocol.

Would that cover what you're trying to get to?

:-)

Russ

- --

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Jul 2007 14:10:30 -0400

> implementations outside the BGP protocol.

Is this practical?  Pass information out of band to every far distant
BGP speaker rather than just to peers.

This seems to break the "must be scalable" requirement for everything
related to routing.

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jul 2007 14:10:18 -0400

Curtis,

a few observations:
	- as I just noted in a prior response, DoS is not the only issue here.

	- the fact that routing does generally work today is not a 
good basis for deciding on security requirements.  If we turn back 
the clock a few years we could say that DDoS attacks never happen and 
thus one need not make provisions to deter such attacks.  As they say 
in the financial sector "performance data shown represents past 
performance and is no guarantee of future results" :-).

	- active attacks against BGP sessions are possible. not all 
BGP sessions make use of extant protection mechanisms like the TCP 
MD5 checksum, and among those that do there are reports of key 
management that leave s a lot ot be desired

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jul 2007 14:30:07 -0400

>  > check is of value no matter how many clueless ASs touch the UPDATE.

The ROA defined by the SIDR work is a good example of a first step 
that acknowledges that some verified info is better than none, a 
point you have been making. It also is an example of a mechanism that 
addresses what some folks say is the most common form of accidental 
"attack" by ISPs, i.e., erroneous origin announcements due to config 
errors. That makes is an appropriate partial solution, since it 
addresses, in a comprehensive fashion, one specific form of problem. 
Also, the ROA model is especially simple, as there is no notion of a 
serial mix of verified and unverified path data, since a ROA attests 
only to origin AS data. Finally, based on the current SIDR 
architecture model, ROAs are  distributed via a repository system, 
essentially out-of-band, and so the argument re transitive 
propagation does not apply here.

>  > The choices seem to boil down to MUST or SHOULD.

Sandy changed her position to MAY yesterday, based on further 
discussion and on Tony's suggestion.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jul 2007 14:00:48 -0400

>an AS Path through unauthenticated AS of unknown reliability.

I think we are in agreement that, under some circumstances, one could 
make good use of path info that is a mix of verified data from 
unknown ASes, plus unverified data from known, trusted ASes. However, 
I also think it is fair to say that there are examples of incremental 
deployment where this is not a requirement. Moreover there are be 
cases where relying on trusted ASes will cause problems, not because 
the ASes are not trusted, but because people make mistakes and these 
mistakes are equivalent to some forms of attacks.

Given this mix of possible scenarios, it seems appropriate to allow 
for solutions that accommodate propagation of mixed (verified and 
unverified) path data, but not to mandate them. Hence a MUST here 
seems too stringent, as that is a mandate. SHOULD expresses a strong 
preference for solutions to accommodate this capability, and MAY is 
neutral.  That's why I believe MAY is appropriate.

>secrets.

DoS is the primary concern, but not the only one. Misrouting to 
effect active or passive wiretapping also was cited as a concern in 
RFC 4272 (BGP Security Vulnerabilities Analysis).

>Choosing a path that is extremely likely to be reliable but

Choosing a path that is extremely likely to be reliable is obviously 
a goal, but having some verified info for a path does not, per se, 
make it "extremely reliable."

>implement and it will never get PS status for lack of implementation.

I have to admit that whenever I hear someone argue that a proposed 
security approach is striving for perfection at the expense of 
practicality, I wince. Thus is a reasonable argument in principle, 
but very often folks disagree about what constitutes a practical (or 
impractical) solution, or a what constitutes reasonable threat model, 
etc.  So, let;s try to not go down this path as a basis for deciding 
about these requirements, as it is unlikely to be a fruitful wa to 
resolve our disagreements.

>drop the attributes at their peerings.

The second argument you cited was not the principle one, but rather 
an example of why mandating this as a requirement might be 
problematic.  I think the argument I have made in this and previous 
messages is that there are a number of incremental deployment 
scenarios where the need for the sort of transitive property you cite 
is not needed, and there are scenarios where it could lead to bad 
decisions.

Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Jul 2007 15:05:22 -0400

> RFC 4272 (BGP Security Vulnerabilities Analysis).

Steve,

As a security guy wouldn't you consider relying on routing to protect
secrets to be more than just a slightly bad idea?

For secure applications you must always assume an insecure channel
even if its in the same building.

With enough snooped data breaking some forms of encryption is
possible so I know what you are getting at.

In terms of real world, it might be possible to divert information
that is supposed to go to some major bank from some far away place and
have a go at the SSL encryption but I suspect its orders of magnitudes
easier to take over the client's Windows box and record keystrokes.

> resolve our disagreements.

At what point do we set theory aside and look at whether we are
addressing any sort of real world problem?  Is your answer "never"?

> is not needed, and there are scenarios where it could lead to bad 

OK.  Lets have some specifics.  What deployment scenarios?  Where
could transitive behaviour that only applies to selecting among
incompletely authenticated results (and can be administratively
disabled) lead to bad decisions?

This would not be the first routing activity of the IETF that was
great in theory but went nowhere because it had no practical
deployment scenario.  If it goes nowhere it is a waste of our time.

Curtis

---

From: Russ White <[email-masked]>
Date: Wed, 18 Jul 2007 15:11:51 -0400

> This seems to break the "must be scalable" requirement for everything

Aren't the ROAs already being transmitted that way?

:-)

Russ

- --

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Jul 2007 15:18:53 -0400

> performance and is no guarantee of future results" :-).

I think you mean turn back the clock a decade.

DDOS attacks are more than a decade old.  DDOS is exactly the sort of
practical problem that the security theorists ignored while the
Internet practitioners advocated hardenning.  The hardenning had
nothing to do with cryptography and in fact cryptography was
impractical.  The security theorists had a very hard time accepting
this and still do, hence our recent discussion on GTSM.  I can dig up
plenty of back email dating from the mid-1990s on DOS hardenning and
DDOS hardenning and *practial* and *deployable* protection against
injection of false routing information.

> management that leave s a lot ot be desired

TCP MD5 is of limited value with GTSM and packet filtering being the
preferred methods of providing such protection.  GTSM for EBGP
peerings.  Filtering for IBGP peerings.

I would also point out that GTSM had very strong ISP support
particularly from AOL (Vijay Gill) because it did solve a practical
problem and vendors had no choice but to implement it promptly, even
before the IETF had acted.  In contranst this work may drag on for
(many more) years and (continue to) yield nothing if practical
problems are not addressed.

Curtis

---

From: [email-masked] (Sandy Murphy)
Date: Wed, 18 Jul 2007 15:45:58 -0400 (EDT)

>these major customer and peer routes from a very limited set of ISPs.

I hear you about the Internet mostly just works.

But we seem to have p-l-e-n-t-y of publically discussed examples of
cases where the trust structure did not not serve us well.

Furthermore, from what major ISP have said, what is said by others
about major ISPs and from the analyses of public data of some incidents,
it seems the case that some major ISPs (Spring comes to mind?) do not
filter well enough to prevent some noticable traffic redirection.
These have been accidents so far, but provide worked examples of
how bad the problem can get.

Relying on the ISP trust and policies is mostly good enough for
mostly just works.

>major ISPs and the authenticaion is of very little use for ISPs.

I agree with you here!  But I don't think anyone is talking about
not allowing auth info to cross major ISPs.  We're mostly arguing
how strong a requirement to make the ability to transit un-upgraded
ISPs: MUST, SHOULD, or MAY.

--Sandy

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Jul 2007 16:00:05 -0400

> Aren't the ROAs already being transmitted that way?

The ROAs do not provide authentication information to accompany a
packet or that pert of an AS path might be legitimate.  It just serves
to verify that a route could be originated at all by a given AS.

If you want to authenticate a routing packet you need a signature over
the packet or a digest.  Its fine to then provide the public keys OOB.

For example, if the AS Path is A X Y Z and I trust my peer A but not X
and Y, the ROA only tells me that its OK for Z to have originated this
route and nothing about whether this could have legitimately passed
through Y and Z.  An authentication would be Z signature, Y signing
that, X signing that, and A passing along the signatures.  If 128
bytes are used per signature that is 384 bytes.

OTOH if some OOB mechanism also addressed whether a peering might be
legitimate, then requirements would be met.  So maybe its just that
the current ROA scheme (or schema) is inadequate.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Jul 2007 17:01:07 -0400

> Relying on the ISP trust and policies is mostly good enough for

This has been true for over a decade.

Back in the mid-1990s ANS days two very major incidents occurred.  One
was the intentional advertisement of very specific routes into PSI for
every DNS TLD servier.  This took out DNS for anyone who beleived
those routes.  It did not affect ANS due to IRR policy.  Another was
announding critical subnets of AOL.  Again that did not affect ANS
since they had specific filters to protect their direct customers and
any peer that wished to register in the IRR.

Even earlier, Sprint, UUNET, and PSI default routed to the NSFNET.
Someone got a 56K circuit to ANS at a university in the middle east
and announced the NSFNET address.  Sprint, UUNET and PSI were a mess
for 10 hours.  NSFNET customers were fine (then it was the PRDB).

There are ways to protect routing today.  Not everyone makes use of
them.  That's been the case for a very long time.  And they are far
from perfect.

> ISPs: MUST, SHOULD, or MAY.

Some providers may never upgrade.  Some mechanism to still pass routes
through them is needed, albiet placing less trust in those routes.

Curtis

---

From: Russ White <[email-masked]>
Date: Wed, 18 Jul 2007 18:41:57 -0400

> to verify that a route could be originated at all by a given AS.

Whether a BGP packet is "authentic" is only a question hop by hop, and
hence, anything transitive you carry within the packet doesn't help you
much.

Whether an AS Path is valid is a long discussion, and we've had it many
times before. Suffice it to say I believe it's possible in many ways
without carrying anything in the BGP packet.

> the packet or a digest.  Its fine to then provide the public keys OOB.

You're treating this like IPsec, where a packet originates at one end of
a connection, and ends up on the other side of the Internet at the other
end of that connection. Wrong. There's no way to know if a BGP "packet"
is "valid," beyond a single hop. You can validate the information
contained within the packet, but "validating" the packet across
"multiple hops," is only one possible way to do it.

:-)

Russ

- --

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 19 Jul 2007 08:35:35 -0400

> without carrying anything in the BGP packet.

I do too but if it involves information using a slow, almost static,
OOB mechanism such as IRR or X.509 based ROA, then it needs some means
of expressing the possible AS adjacencies and the policies applied
over those adjacencies.  If so, we're right back to RPSL.  We might as
well just pick up that work and use a different underlying delivery if
the RPS work was considered unacceptable.

> "multiple hops," is only one possible way to do it.

Sorry.  Should have said advertisement.

Curtis

> iD8DBQFGnpc1ER27sUhU9OQRAtgLAJwO7/Q/n6jjdFLDs/tA93HI74ZFywCgzJXU
> 12xxdMHHt2SAQRX2bAgCSLk=
> =7vX4

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jul 2007 09:40:36 -0400

>> the RPS work was considered unacceptable.

Perhaps we should leave out the actual mechanisms, and just leave the
option for out of band delivery open. :-)

>> Sorry.  Should have said advertisement.

Really, advertisements aren't end-to-end in BGP, either. Any time you're
designing something, and have to start making exceptions to the rule for
each situation brought up, you should probably go back and rethink the
paradigm your using. The AS Path is our favorite "whipping boy," but, in
reality, the AS Path is just one attribute among many in BGP, and, like
other attributes, the AS Path is mutable. So far, we've discovered:

o AS Path Prepend
o AS Path Stripping
o Aggregation
o Local AS

At least that change the processing rules for the AS Path, or change the
AS Path itself. If we think of the AS Path as being constant end to end,
and plan security based on that thinking, then we must think in
exceptions to the rule set for each possible modification to the AS
Path, and as people think of new ways to modify the AS Path, we have to
think of new exceptions to the rules.

It seems, to me, that it's easier just not to think of the AS Path as
anything more, or less, than an attribute among attributes, all mutable
for various reasons. This allows us to stop thinking in terms of an
"end-to-end" advertisement, and see BGP for what it really is: A
distributed database system in which each device along the way might
change the data in subtle or not-so-subtle ways, and for valid reasons.

The question then changes from: "Who has touched this," to: "Is the data
valid?" Of course, then you have to decide what "valid" means, but,
there we digress into a lot of other conversations we've already had,
and I don't want to repeat. :-)

Going back to the original question:

The basic point, to me, is that the validity of the data is not a
"true/false" situation. Hence, it's possible that passing information
through or around a non-implementing AS, whichever way you want to put
it, has potential benefit. There's no way to know that until you
actually look at the way the proposed mechanism works, though.

:-)

Russ

- --

---

From: "tom.petch" <[email-masked]>
Date: Thu, 19 Jul 2007 16:42:05 +0200

I am very much with Curtis on this one.  What he says seems pragmatic
engineering, allowing the Internet to evolve to a better place.  I would go for
a MUST in the protocol at this stage.

Tom Petch

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 15:06:32 -0400

>bytes are used per signature that is 384 bytes.

We really ought not get into details on specific techniques, as Russ 
noted. For example, if one uses a fancy EEC signature scheme that 
allow signature aggregation, the total for the three signatures is 
about 128 bytes.  (See the PhD work by  Meiyuan Zhao at Dartmouth 2 
years ago.)

>the current ROA scheme (or schema) is inadequate.

The ROA scheme has a specific purpose, i.e., allowing a resource 
holder to express an globally-verifiable authorization to originate a 
route to the holder's prefix(es). ROAs ought not be criticized for 
not doing something that they are not intended to do.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 14:44:50 -0400

>this and still do, hence our recent discussion on GTSM.

It seems that you took my reference to DDoS to mean attacks against 
BGP session on routers. I was referring to the broader problem of 
such attacks against subscriber end point or links. In that broad 
context, almost all of what you say above is not accurate:
	- security folks noted this potential for such attacks before 
they occurred
	- ISPs ignored the warnings because they had not seen the attacks
	- the security community generated a lot of papers on the 
topic, some good some bad
	- a few start up companies were created to deliver technology 
to address the problem
	- ...

As for GTSM, yes, it is a simple fix for a class of off-link attacks, 
and there's nothing wrong with that. If ISPs decide to stop there, 
and not also employ crypto-based mechanisms that addresses on-link 
(or, more properly on the same L2 net) attacks, that's a local 
decision based on a perceived threat. However, it still makes sense 
for the IETF to develop such mechanisms, for those ISPs who do choose 
to employ them.

>   I can dig up

A common theme in your comments is "practial [sic] and deployable." 
There's nothing wrong with those goals, although I would add "secure" 
as well :-). The problem, of course, is getting agreement on what 
constitutes practical, deployable, and secure.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 15:13:52 -0400

>think of new exceptions to the rules.

Of course the path is not an e-2-e constant, since it is legitimate 
for it to change, in certain ways, as the path info passes through 
each AS. However, I don't think we believe that all possible changes 
to the path are legitimate at each hop. That suggests that it may be 
possible to express what the allowed transformations are and develop 
mechanisms that allow the recipient of the path info to verify 
whether the received path is legitimate relative to the 
transformations that have been applied.

>change the data in subtle or not-so-subtle ways, and for valid reasons.

see comments above that apply here too.

>and I don't want to repeat. :-)

and yet you are repeating them :-(

>"true/false" situation.

I don't think we have a string basis to believe that this is 
undecidable. The examples you cite merely show that it's not trivial, 
but then routing is not trivial even absent security considerations.

>Hence, it's possible that passing information

I agree that it MAY have benefit (i.e., potential benefit) but since 
it also might be harmful, or might not be necessary, it seems 
inappropriate to mandate support for it in our requirements.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 15:03:12 -0400

>secrets to be more than just a slightly bad idea?

WRT content disclosure one certainly ought not rely on the path for 
confidentiality. Hiwever, very little Internet traffic is encrypted 
today, so it still makes sense to consider this as a valid concern. 
Moreover, traffic analysis is a confidentiality concern for some 
folks, e.g., in the DoD. Avoding routes that would cause traffic to 
pass through an AS where TA might be effected is a reasonable goal as 
well.

>even if its in the same building.

I have no idea what you're saying above.

>possible so I know what you are getting at.

No, you don't :-).

>easier to take over the client's Windows box and record keystrokes.

That's not what I am alluding to, so let's not waste time arguing 
over what you think I might have said, but didn't really say :-).

>addressing any sort of real world problem?  Is your answer "never"?

Sounds like you're asking if I have stopped beating my wife yet? :-)

SSL/TLS is very widely used, yet it's primary protection is against 
wiretapping attacks that rarely occur. (It also is supposed to 
provide authentication that we are connected the the site we think, 
but the PKI model used with browsers limits the ability to achieve 
that goal.) In reality, your credit card data is at much greater risk 
when it arrives at a web server vs. while it is in transit. I believe 
that the concerns we're addressing here are at least as valid as 
those addressed by TLS.

>disabled) lead to bad decisions?

In a message earlier this week I suggested that a likely deployment 
scenario might be that big ISPs are the early adopters, followed by 
their customers.  In such instances there are no intermediary ASes to 
worry about.

Your second question seems to be a mix of two things. Let try to 
re-phrase.: What bad thing might happen if an ISP uses partially 
verified data to select a path when the only paths he has for the 
NLRI in question are all unverified? You also add in a parenthetical 
allusion to the ability to administratively disable something, 
presumably you mean the ability to turn off checking the verified 
path data when it is only part of an overall path.

A bad thing that might happen is that the ISP might configure the 
router to automatically prefer any route that has at least SOME 
verified path components, an easy policy to express, but one that 
also is naive. Trying to express a more reasonable policy, e.g., one 
that take into account known "trusted" ASes and a mix of verified and 
unverified path elements is very complex.  We developed a set of 
policy controls that tried to do this a fee years ago, and decided 
that the result was so complex as to create more problems than it was 
worth. We decided that only a simple policy setting, i.e., my peer 
has security enabled or not, was easy enough to be practical.

It seems that many ISPs have trouble predicting the impact of route 
configuration choices today (c.f. RFC 4264 "BGP Wedgies"). I think it 
is not unreasonable to extrapolate this sort of experience with 
complexity to the routing security context and come the the 
conclusion that we ought not create an environment that makes it 
likely that folks will have the same problems.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 14:44:50 -0400

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 15:13:52 -0400

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 15:03:12 -0400

No, you don't :-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 14:44:50 -0400

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 15:13:52 -0400

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 19 Jul 2007 15:03:12 -0400

No, you don't :-).

Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 19 Jul 2007 22:41:07 -0400

> constitutes practical, deployable, and secure.

Practical and deployable should be goals if we want to see something
deployed.

Secure where there is no portion of the path containing
non-participant AS should be a goal.

Providing indication of better confidence with certain semi-trusted
non-participant AS in the path should be a goal.

Regarding Russ' comments: OOB is not excluded but any OOB solution
must meet requirements regarding AS Path, not just origin AS.

Do we have agreement?

Curtis

ps - If you are talking about general DDoS attacks, providers knew
this was possible.  They would rather see Bill Gates hung for
providing the insecure OS that made DDoS bots so easy to implement.
The point was that not much can be done from the provider's standpoint
for DDoS to end sites.  Now if the Feds confiscated PCs involved in
attacks, spam, etc, sent the PCs back to the supplier to apply
patches, returned the PCs, and sent the bill for the investigation to
the OS vendor, we'd have the problems all solved.  :-) Users of free
or homegrown OS would have to apply patches themselved before bringing
computers online again.  [No chance of this happenning - just a dream.]

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 19 Jul 2007 22:46:24 -0400

> not doing something that they are not intended to do.

ROA should be criticized for a major ommission relative to an existing
scheme it is expecting to replace.  But we're off topic.

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jul 2007 09:59:02 -0400

>scheme it is expecting to replace.  But we're off topic.

Perhaps more accurately, we're talking about this in the wrong WG.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Jul 2007 17:47:08 -0400

>Practical and deployable should be goals if we want to see something

I'd list security at the same level as practical and deployable, 
i.e., without further qualification, since the whole purpose of this 
requirements document is security.

>non-participant AS should be a goal.

I think we can agree on something of this sort, perhaps with revised wording.

>non-participant AS in the path should be a goal.

We don't agree on this point, if the goal translates into a MUST, for 
the reasons we've discussed in previous exchanges.

>must meet requirements regarding AS Path, not just origin AS.

The problem with OOB is one of timeliness. For origin AS there seems 
to be agreement that the binding between a prefix holder and the 
origin AS is fairly stable, so OOB distribution of this data is OK< 
at least most of the time.  There has been less agreement about 
whether the bindings between successive hops in a path are 
sufficiently static, and limited in fanout, to make OOB distribution 
acceptable. For example, OOB distribution can provide a set of routes 
that might be "legitimate" based on transitive closure, but that set 
may be bigger that the set of routes that are ever advertised. At 
best, the set of routes generally will be bigger that what is 
currently being advertised. In some contexts that may be adequate. In 
other contexts the set may be so big as to not provide acceptable 
security. That's why the question of OOB distribution is not an easy 
one to answer.

>Do we have agreement?

not exactly.

>providing the insecure OS that made DDoS bots so easy to implement.

Maybe fair wish (said the Mac user :-)), but from a security 
standpoint that's not a great strategy anyway. The fact that there 
are lots of vulnerable machines that can be turned into zombies makes 
this problem especially bad, but one would never want to rely on good 
security practices by every user as a defense anyway.