Subject: RE: [RPSEC] proposed message to the IESG

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 Jan 2005 18:43:49 -0500

Russ:

Please confirm that when you mean prefix and attributes associated with
that prefix that you do not care about: 

1) grouping of the prefixes with attributes within a packet, or
2) the order of the prefixes across packets

Because I would care if :

Announce, withdraw, Announce turned into
Announce, Announce, Withdraw

Or
Announce, Withdraw, Announce turned into
Announce, Withdraw, Announce, Withdraw. 

So this can happen with attacks along the way.  I would care.  I would
care to find out how it was packaged to track how this change occurred. 

If I could prove these changes were inserted by the White foundation for
bad packets -- I would really worry.  (You'd have finally gotten me back
for all those tons of questions on OSPF). :-)...

So, tell me what I misunderstood in your message.  I gotta believe I
missed something here.

Sue

-----Original Message-----
From: Russ White [mailto:[email-masked]] 
Sent: Thursday, January 20, 2005 6:27 PM
To: Sandy Murphy
Cc: [email-masked]
Subject: Re: [RPSEC] proposed message to the IESG

> I think you mean "convincing" when you say "proof" and you and Steve 
> aren't agreeing to the same ground rules to convince each other.
>
> To some people, proofs of security features go something like this:

> (a) the spec says things should happen like this
> (b) it is possible to make things not happen like this
> (c) QED

The problem is in this: How do you describe what the specification 
specifies?

-- Is there a concept of an "end to end" thing called an "update," and 
you're trying to prove "authorization" to readvertise this "update?"

-- Are you trying to prove certain things about the information
advertised 
to you by a peer (using an update, with many other pieces of information
in 
it), are "true," in some sense? What are the questions we need to ask
about 
this information?

IMHO, just because the BGP specification says "the update is then
processed 
using method x...." doesn't mean an "update" exists as an atomic thing 
within BGP.

> OK, so I'm generalizing a lot.  But the core point is that security 
> relies on assumptions holding.  Sometimes those are innate (the IP 
> address in the source field is the address of where this comes from)
and 
> sometimes it derives from the spec (the spec says that the message I 
> received is generated when the source received my message, therefore I

> can assume that the source received my message).

Yes, exactly. IMHO, we should ask what we can prove about a specific
piece 
of information, and require certain things be found true. For instance, 
saying: "I want to prove this update was received from x, at time y, and

hasn't been altered," doesn't answer any real questions. _Why_ do you
want 
to prove those things? What is it you hope to prove by showing this
update 
came from x at time y?

If the answer is anything other than: "proving the packet was
transported 
along a certain path at a certain time," then you're not at the 
requirements stage--you're still at the solutions stage, simply trying
to 
push a solution off as a requirement.

When the data is opaque, and the packet is "pushed into a tunnel" on one

end, and "pulled out of the tunnel" at the other end, you have
end-to-end 
security. If you're looking for end-to-end security, it might be
sufficient 
to prove every node along the way touched the packet in a certain way.

It's a completely different game when everyone along the way can pull
the 
information out, repackage it, and possibly alter it. There's no concept
of 
"end-to-end" in the BGP protocol in this way.

Let me also point out that I assert an "update" isn't what I'm
interested 
at all in BGP. I'm interested in a prefix and it's attributes. One of
those 
attributes happens to be the as path, and you can make assertions about 
that as path. There's no such thing as "the update" in the same sort of 
context as "the packet" in an IP flow.

:-)

Russ

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

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

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

---

From: Russ White <[email-masked]>
Date: Thu, 20 Jan 2005 18:58:39 -0500 (Eastern Standard Time)

> 2) the order of the prefixes across packets

The grouping of the prefixes with the attributes. How these are placed 
inside packets is of no concern to anyone that I can think of.

> Announce, Withdraw, Announce, Withdraw.

It's actually quite interesting you would use withdraws as an illustration. 
Let's say I have this:

10.1.1.0/24----A----B---C---D
                |        |
                +--------+

Now, let's assume C is using the path through B to reach 10.1.1.0/24, but 
also has the path through A. When A->B fails, what happens?

-- B sends a withdraw for 10.1.1.0/24 to C.
-- C examines its local table, and finds the althernate path via A.
-- C sends an update to D stating the AS Path has changed from {A,B,C} to 
{A}.

Notice what's missing? D never got B's withdraw. D implies that C is 
withdrawing the first route, because it sent the second, and BGP can only 
send one path to an eBGP peer. Again, there's no such thing as "the update" 
or "the withdraw" in BGP. What I care about is that the final state of the 
database on a BGP speaker matches reality.

> So, tell me what I misunderstood in your message.  I gotta believe I 

No, I just think you're having a hard time with the non end-to-end nature 
of this system. BGP is explicitely designed to transfer information. The 
actual format in which the information is transferred is intentionally 
loose, to allow modifications to the protocol, and to allow accrued 
efficiencies in implementations and throughout the system.

:-)

Russ