Subject: Re: [RPSEC] Back to the Basics: The AS Path

From: Blaine Christian <[email-masked]>
Date: Sun, 23 Jan 2005 23:29:03 -0500

Responses inline...  I just want to give this one more shot...  The last few
paragraphs have the most meat.

I should preface with stating that I almost always take the devils advocate
position in an argument.  I am finding value in the discussion and about
three emails back from Russ I caught some of the best discussion points yet.

On 1/23/05 8:53 PM, "Russ White" <[email-masked]> wrote:

> 
>>> -- The requirements document should state any proposed solution must
>>> verify/prove/etc. the path the routing information actually took is the
>>> same as the AS Path attribute of the route.
> 
>> Hey Russ, can we work this backwards a bit and see it if still makes
>> sense? Perhaps we can list the cases where the path can not be proven and
>> still allow for path verification?
> 
> Hmmm.... What do you mean by "path verification?" Do you mean proving the
> routing information has actually passed through the AS' listed in the AS
> Path? I'll assume so....
> 

I am certain that I would like to be able to "affirm" that the update
traversed the stated path.  I suppose this also means "prove".  I am not so
certain that I can see all the permutations where this would not be the
case.  I really did want to work this backward and see if we can come up
with a limited subset of things that fall outside of verifiable.  I am also
not so certain that this needs to be done real time or that a potential
option would not be to just declare paths that are verifiable to be
"secured" and paths that are not verifiable to be "not secured".

> Let me start out by stating this: The claim is that this wording:
> 
> "The receiver of a specific prefix/attribute MUST be able to verify the
> routing information has passed through every AS peering pair in the AS
> Path."

This is impossible as currently worded due to the exceptions we already
identified.

> 
> Should replace the current wording in the BGP requirements draft, because
> it is supported by this:
> 
> "According to the BGP specification (or according to what the BGP
> specification SHOULD read), each AS handling the AS Path MUST insert their
> AS in the AS Path. Further, no information may be removed from the AS
> Path."

As worded, not a likely addition to the text.

> 
> I believe you've already conceded, below, that this simply isn't the case.
> I'll work with that assumption, since the tenor of the rest of your email
> seems to assume that, but it would, actually, be nice to get a statement on
> whether you believe using the sense of the BGP specification, or the BGP
> specification itself, justifies changing the current wording.... :-)

Well, I am quite comfortable in stating as follows:  The deployment of any
new "replacement" system relies heavily on the state of the existing system.
As such, the BGP specification takes second place to the great unwashed mass
of actual implementation.  If you want to deploy something to
replace/upgrade an existing system you need to take into serious account the
existing implementations, features, and the needs of the users.

> 
> Based on my reading of your email, I'll assume you're now trying to justify
> changing the wording on the draft to something close to the one listed
> above based on a desire for non-repudiation--that's it's important to know
> who, exactly, forwarded a specific piece of routing information, so you can
> hold the originator and forwarders of that routing information liable
> (legally or socially) for originating or forwarding false routing
> information. I'll deal with this more at the end of this email.

You know it!  Not sure the wording of the draft needs changes but the desire
to be able to identify issues does exist.

> 
>> 1. Reoriginations: This is information reduction/expansion for the sake
>> of performance and it could be argued that it is a tacit agreement
>> between the provider of reoriginated information and the reoriginatee.
>> If it is an agreement between originator and originatee then security
>> would most likely also be an agreement betwixt the two.  Heck, if I do
>> BGP with a customer and advertise default this is essentially the same
>> thing.
> 
> This doesn't negate my argument that informaiton is removed from the AS
> Path, and therefore the AS Path attribute of the route doesn't actually
> match the path of the routing information through the network. However,
> you're claiming that since this only occurs in the context of a customer
> and their provider, it just doesn't matter that information is removed from
> the AS Path.
> 
> Okay, I understand your argument, I believe. The problem is you don't know
> if the customer has actually authorized, from the information in the
> reoriginated route, the advertisement of this routing information. So, you
> can't prove authorization, in this case, only non-repudiation. You can try
> to prove the customer's provider actually advertised the route, you can't
> prove the customer authorized the provider to do so.
> 
> In fact, the provider could be maliciously advertising the customer's
> address space, even though a previously valid agreement allowing them to do
> so has now been voided because of some "falling out" between the two.

Ahh, my apologies, we had our sides reversed.  I was more focused on the
typical case which was the reduction of route information on the behalf of
aging equipment, sheer desire for improved switch over speed, or load
sharing.  In most cases, that I am aware of, the reoriginator is usually the
owner of the block being reoriginated.   The "owner" of the block advertises
it and does whatever the heck they want with it (assuming they use at least
80% of it <grin>). 

> 
>> 2. Confederations: These happen "internal" to an AS so I suppose this
>> could just be captured and dealt with separately.
> 
> Again, the point of the argument is that information is, in fact, removed
> from the AS Path, not that it's "internal" to an AS or not, simply that it
> happens. It would be different if the Confed AS' were inserted in a
> completely separate attribute that could be removed separately, rather than
> modifying the AS Path, but in reality, they aren't. They are inserted into
> a confederation set within the AS Path itself, and the confed set is
> stripped out of the AS Path at the other side of the confed.

No argument here... I was shooting for a list of things that are "less than"
verifiable.

> 
>> 3. Private AS stripping:  Most folks do not allow this type of stuff to
>> propagate beyond the initial two networks involved so again it should
>> fall, mostly, in the realm of a private agreement.
> 
> Again, however, just because it happens in the private context doesn't show
> that information isn't being removed from the AS Path, correct? Again,
> you're arguing, as above, that it doesn't matter, because it's a private
> context.

Yes, I am saying that in a private context people can/should do whatever
they want within their networks.

> 
> A BGP speaker receiving this route would only be able to assume it has the
> entire AS Path, and that the originator is authorized to originate it.
> However, unknown to the receiver, there is actually another AS in the AS
> Path, and there's no way for the receiver to know of the original AS
> actually authorized the advertisement of the routing information by the
> apparent originator from the routing information itself.

Yes, but a private AS is an internal device used to do internal things.  If
it was stripped out it should be okay and the system would have to deal with
it.  

> 
> Seems like a lot of assumptions, to me. Again, we're in the same position
> as reorigination, where we can try to prove non-repudiation, but not
> authorization.

I am not sure about authorization.  This starts us traipsing our way back to
a central authority models that give me the willies.  How about, three
people that I trust said they trust a fourth person.  Since they trust that
person I trust that person (just not as much as the first three <grin>).
And since some types of customers are really picky throw in a strict
hierarchy ability (already in the draft folks).

> 
>> 4. Route propagators (really just packet forwarders for all intents and
>> purposes).  A packet forwarder is a packet forwarder.  As long as
>> whatever security information is necessary is passed along as well I
>> don't think this is really germane to the discussion.
> 
> ?? I don't really understand this one.

Hmmm, route policy servers?  Packet scrubbers?  Wacky stuff that does BGP
magic in an attempt to optimize cost/latency etc..?  I admit, it was a
catchall.

> 
>> Can anyone think of other special cases such as the above?  Would
>> everything else be "verifiable"?  Just above every one of the above path
>> manipulations is based on either a private agreement or an internal
>> optimization for a network.
> 
> Just about.... But, you're dealing with a separate problem here. You're
> morphing the issue from:

My apologies for any morphing.  But you started it with Sandy <grin>.  I
can't help it if it was a great discussion.

> 
> -- "Does the BGP specification support changing the requirements currently
> listed in the requirements draft to some other wording?"
> 

My two cents is that the implementation and non-flag day deployment issues
should come first in any discussion.  There are several significant BGP
implementations out there.  We need to be able to keep this thing up while
it is evolving into a more secure system.

>   -- TO --
> 
> -- "Does the requirement for non-repudiation support changing the
> requirements currently listed in the requirements draft to some other
> wording?"
> 
> I believe non-repudiation is already covered in the current text of the
> draft, and I don't have an argument with it being there. So, I'm not
> certain why the wording would need to change to include non-redudiation.
> But let's run with the argument that non-repudiation _could_, possibly
> justify changing the current wording, and see where it takes us.
> 
> What do we know about non-repudation, as a concept? We know that other RFCs
> state, quite clearly, that non-repudiation isn't possible. So, you're
> making something acknoweldged as not possible a MUST. IMHO, that's not a
> good idea. In fact, I'll just about bet the wording on non-redudiation is
> removed from the draft or, at the least, altered radically, before it's
> actually pupblished, based on the reasoning I've seen from the security
> folks in the past. :-)

Not sure non-repudiation needs change...  But if security folks are going to
give us a hard time, even though we worded it pretty loosely, then so be it,
we will adapt.  If folks will be overly strict in interpretation then we can
work on the language.  Suggestions are always welcome!

> 
> Now, let's run a different direction, and see where it takes us. Let's
> assume we _do_ make this wording change, and then we have to build a
> justification for the wording in the draft. What would the justification
> be? Since we can't justify the requirement with: "Because the BGP
> specification says so, or it should say so, and it doesn't," then we have
> to find some other justification, correct?
> 
> That justification would be the requirements, as they are currently stated
> in the draft. Interesting.... If you have to justify the requirement with
> the current requirements, why change to some other requirement at all? I
> suppose I'm just confused on this point.... If I justify a requirement with
> something previously listed as requirements, it sounds like I'm moving into
> the solution space, instead of the requirements space.

You know, I was about to start this response with the words "chicken and
egg" but stopped myself.  Lets take a step back and talk about a network and
an AS.  I am thinking that we are bit bound up in thinking that one network
equals one AS.  This is patently not the case and I think we all know it.
One network I worked on had about 10 in active use.  I could really care
less about whether the AS path was verified for inbound prefix
announcements.  What I DO care about is identifying how the prefix
announcement arrived at my doorstep.  For the very first external network I
connect to it is easy.  But take a step further in and the problem becomes
very complex.

Unfortunately, the only tool we have to tell us how the update arrived at
our door step is the AS path.  Most of the time that AS path is pretty
reliable.  We get a chain of providers that, in an operational role, we can
go and contact individually to identify exactly where a forwarding problem,
or routing issue, might exist.  However, there are occasional cases where
announcements/withdraws reach our network that were, in no way, acceptable
announcements/withdraws.  Sometimes these announcements happen so quick we
do not catch them (these are the ones that really bother me).

Enforce first AS helps maintain a chain of responsibility and may actually
help to resolve the evidence problem.  Unfortunately, if it does not get
widely implemented it is useless.  The same thing could be said about
security in general though.  A twist on this might be that if we knew that
the entire path had enforce first AS enabled, and session security enabled
between each set of peers, we could assign a different level of trust to
that path vs. a path received without enforce AS enabled (a gauge to full
implementation at least would help).

To take a slightly different tack, and one I have been pushing.  It is all
well and good to have a wonderfully complex and highly secured system but if
we can't tell when/if something is being abused in that system it is
worthless.  Also, the pain I experience from actors that are more than one
AS hop away is usually the most exquisite.  If we can't improve the system
at a distance of more than one hop then I would hesitate to push forward.

Now, reviewing all that blather that I put forth in the above, all I see is
that we still have a system where folks can potentially abuse things.
However, what we can possibly get is a mechanism to identify and deny
abusers.  We need the last part of the key to make this part work.  What we
need is the ever ephermal idea of "authorization".  If we are using one of
our nifty new protocols to propagate "ownership" of prefix space the reuse
of that tool to secure peering sessions seems tantalizingly close.  This
leads us back to the idea that the path is "plausible".  If a
announcement/withdraw has passed the hurdle of enforced first AS, has
traversed secured inter-as connections, exists, and comes from a "trusted"
party then it would certainly be plausible.  It actually seems highly
probable. 

Does this make sense?  What we would not have, in the above, would be end to
end security of the actual advertisement.  I am not sure how end to end
security of an advertisement is possible when each AS makes it's own magic
with advertisements.  Even if I end to end secured the advertisement it is
still defeatable internal to any of the networks.

> 
>> You know that, no matter what happens with the specification, the ability
>> to track signatures across an entire AS path is quite attractive as a
>> means of identifying miscreants or potential issues.  Even if noting and
>> ignoring the special cases does not work.
> 
> This is a solution, not a requirement, so I won't go there....
>

Okay... Remove the word signatures.  The ability to be "more sure" that the
update traversed a set of networks (note I pulled the term AS path out) is
attractive.
 
> The special cases, combined with the problems inherent with
> non-repudiation, kill off non-repudiation as a justifaction for the change
> in wording, IMHO.
>
>> Another thought... We did build into the requirements draft language that
>> allows for non-secure things.  Wouldn't unverifiable stuff just end up in
>> the "not secured" realm anyway?
> 
> You don't know if they are or aren't. If you remove information from the AS
> Path, you can't tell what that information was, so you can't say: "Oh, this
> is just less secure, because information has been removed from the AS
> Path." Second, you can't deny that in many of these situations, the removal
> of information is such that the originator should still expect their routes
> to be treated in a secure way.
> 

That is true...  I suppose my thinking is that people already secure their
internal network bits and getting anal about someone ELSES network is pretty
futile.  Either they are going to take care of it or not.  If we can
identify that they are a source of hacking they will either adapt or wither.

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

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 14:16:55 -0500 (EST)

>> Ouch.  People actually operationally add arbitrary AS's to the AS_PATH?
>
>Normally, AS's are prepended by the AS sending the update (in other words
>they prepend their OWN AS not someone elses).

Yes, well understood.  It was the *arbitrary* AS prepending that I
was asking about.  Judging paths as valid that have the same AS several
times in sequence is no problem.

>Lump multiple, identical, AS numbers together and you should be able to
>still check pairwise.

Same way works if you are trying to judge by AS's transited.

>> Any chance this could be considered a current operational behavior
>> that would be deprecated as faciilitating abusive practices?
>
>Not much of a chance.  Very widely used.

Understand what I'm trying to say here.  It is prepending *ARBITRARY*
AS's that I don't quite see a way to secure right now.

It's the *ARBITRARY* nature that is the problem, not the prepending.

Please - don't go thinking (or saying) that I have spoken out
agains prepending multiple copies of your own AS.  I haven't.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 15:41:41 -0500 (EST)

Stefan Mink says:

>I agree with you that this is the current state, but is it granted to
>always be like this? What if for whatever reason an RIR changes
>its policy... ? This would have to be somehow taken into account
>when verifying the origin authorization of a route.

One can only devise the security protections with respect to the
current requirements for authorization.  If the authorization
definitions change, then the security protections have to change
as well.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 15:42:18 -0500 (EST)

>I agree that MUSTs must be followed, but not that missing "MUST NOTs"
>mean its allowed. I'm sure no document is complete in this sense.

I agree wholeheartedly!

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 15:48:42 -0500 (EST)

Jeff:

>Thus, a compliant implementation will only _prepend_ AS numbers.

That would be my interpretation, also.  (with the exceptions noted by
you later)

>:   If the UPDATE message is received from an external peer, the local
>:   system MAY check whether the leftmost (with respect to the position
>:   of octets in the protocol message) AS in the AS_PATH attribute is
>:   equal to the autonomous system number of the peer that sent the mes-
>:   sage. If the check determines that this is not the case, the Error
>:   Subcode MUST be set to Malformed AS_PATH.

Thanks for pointing this out.  So even if the spec does not say MUST
prepend, it makes non-prepending a session ending error if caught?
That would mean that an attempt to exploit non-prepending would have
to depend on the recipient not checking.  (Not that the bad guys are
reluctant to take advantage of checks not being performed.  ;-})

>  Removing private AS numbers may introduce loops if done improperly.
>  However, the scope of these loops are usually localized to the
>  private ASes which are usually stub ASes.

You say nothing about loops introduced by deleting AS's other than
private AS's and other than at the end of the path.  I said that I
thought such deletion could lead to loops.  Do you think so?

>Ergo, the only requirement for loop free operation of the protocol
>is that the AS be present in the path.  In general, you should receive
>your routes with your peer's AS at the start of the AS_PATH.  The
>protocol will work properly if the path is re-ordered.

I think you imply here that you see a chance for loops if AS's are
deleted from the path.

I think I said that I didn't see an attack from reordering the
prefixes, that at least it wouldn't pose a problem for the loop
detection.  But that I could see the potential for problems if
policies in the future started relying on the adjacencies in the
AS_PATH, which you may have meant when you said

>Operationally, people rely on the adjancencies for policy.  This is 
>outside the protocol specification.

So, were you saying here that reordering might make it impossible for
people to "rely on the adjancencies for policy"?

>Four: The security infrastructure should just deal with these things
>as they're not insurmountable.  Only the arbitrary addition of ASes
>is problematic.  Compliant implementations will follow the prepend rule.
>Truncating the path must be dealt with for aggregation.

I agree completely!  Especially the "problematic" nature of *ARBITRARY*
addition of AS's. (note well: I've no objection to prepending your own AS).

And aggregation points are another tough problem for the security
definition.  As you have said, this is not really difficult if the
aggregation point is doing what you call "implicit aggregation" and
owns the aggregated prefix.  And, as you say, not so easy to do for
proxy aggregation.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 24 Jan 2005 17:30:07 -0500 (EST)

>Funny enough, considering the group of people who are discussing this.  The
>cited need was that when someone is hacking at you from a specific AS you
>can deny your route to that AS.

I thought I had heard stories of assembling a path of providers who
cooperated to discover the source and shut it down.  For single sources
only, of course.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Tue, 25 Jan 2005 11:13:58 -0500 (EST)

>        e.g. i originate prefix 192.168.53.0/24 from AS 4555...
>        by what means does someone/someprogram deterministically
>        decide that AS 4555 is "mine" and is allowed to properly
<        originate a path to said prefix?
>
>        if the answer is via the WHOIS protocol, then there are larger
>        fish to fry than RPSEC... :)

I think you are saying that we'll need to build/adapt an infrastructure
that will be able to represent allocations of prefixes to AS's,
as well as authentication of the speaker.    

Yes, I think that everyone understands that this is a necessity
and that it alone will be a tough thorny problem to solve,
both from a practical standpoint (the existing databases are inaccurate,
incomplete, etc.) and from an ideal standpoint (there are
relationships that are not your typical relationship that will
have to be representable).

--Sandy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 26 Jan 2005 15:00:54 -0500

AS confederations use e-BGP within an AS.
Private AS are used there.

Jeff gave you 65000 example.

sue

-----Original Message-----
From: Sandy Murphy [mailto:[email-masked]] 
Sent: Monday, January 24, 2005 4:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [RPSEC] Back to the Basics: The AS Path

>Private ASes can be used for whatever purpose you want.  However,
they're
>not supposed to be visible in the public Internet.
>
>In order for private ASes to be visible, you have to put them in your
eBGP
>sessions.

Can I put these two statements together to conclude that private AS's
aren't supposed to be in your eBGP sessions?

--Sandy