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

From: "Manaila, Florin" <[email-masked]>
Date: Fri, 21 Jan 2005 09:26:39 +0200

Hi all,

I have to agree with Russ, when is saying that "BGP is explicitely
designed to transfer information".
So, in this way we have to work to secure the "transport layer" not the
information witch BGP is transfer.

Regarding, the authenticity of the information passed through the BGP,
YES we should care also by this, but I think that this is a different
side of the "BGP security".

I believe that if we will try to combine this 2 parts we will have many
delays before to take some conclusions.

Best regards,
Florin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Russ White
Sent: Friday, January 21, 2005 1:59 AM
To: Susan Hares
Cc: [email-masked]; Sandy Murphy
Subject: RE: [RPSEC] proposed message to the IESG

> 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

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.

> Because I would care if :
>
> Announce, withdraw, Announce turned into Announce, Announce, Withdraw
>
> Or
> Announce, Withdraw, Announce turned into 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 
> missed something here.

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

__________________________________
[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: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Jan 2005 10:25:01 -0500

Florin,

> information witch BGP is transfer.

In what way do you think that neither TCP+MD5 nor IP Sec covers this
particular issue?

-- 
Jeff Haas 
NextHop Technologies