Subject: Re: [RPSEC] BGP Requirements Draft

From: Sandy Murphy <[email-masked]>
Date: Fri, 23 Sep 2005 13:07:11 -0400 (EDT)

>There's no way to state any AS along the AS Path has been authorized to 
>retransmit routing information it's received. The first question that 
>comes to mind is: "Authorized by whom?"

Of course there is.  Sending the UPDATE *is* authorization to
propagate the UPDATE.

Anyone who looks at the BGP protocol has to recognize that the
BGP protocol itself might propagate any UPDATE it receives.

Kinda like email.  There is no way in the mail system to prevent
someone from forwarding your email, so you have to recognize that
sending the message authorizes them to do what they like.

And in email, just as in BGP, there might be outside-the-protoocol
mechanisms in which you would negotiate and state that you do
not want the message propagated.  But the protocol itself is
not party to that negotiation or carries any state representing
that negotiation.

So the protocol can't be responsible for anything more than what
the spec promises.  And the spec promises that if you send
something, it can be propagated.

Now.  If you would like to be able to authorize propagation of
the messages, then you have to modify BGP to carry some state
that represents that authorization.  (And you have to imagine
how you would enforce that authorization, which would be quite
difficult.  Detecting violations of the authorization would
be possible.)

But until you modify BGP in that way, the BGP spec as stands
means that if you send an UPDATE you are authorizing
the recipient to propagate it.  Any other authorization has
to be a wrapper around BGP, something external to BGP, not
part of BGP.

--Sandy

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

---

From: Russ White <[email-masked]>
Date: Fri, 23 Sep 2005 22:08:47 -0400

> Of course there is.  Sending the UPDATE *is* authorization to

That's the problem, precisely. Are you trying to authorize someone to 
send a specific bundle of bits (an "update"), or a bundle of routing 
information (reachability)??? One of the problems here is that BGP isn't 
about sending "updates." It's about sending routing information. Note 
that 10.1.0.0/16 _contains_ 10.1.1.0/24. If the owner of 10.1.1.0/24 
cannot control the advertisement of 10.1.0.0/16, then it's meaningless 
to say that the owner of 10.1.1.0/24 can "authorize" the advertisement 
of their address space in any way.

updates != routing information

Updates contain routing information, but all the routing information 
about a specific reachable block of addresses is _not_ contained in a 
single update. BGP isn't about building updates and sending them, it's 
about sending reachability information, including some various forms of 
policy. The focus on securing a specific bundle of bits is misplaced.

> sending the message authorizes them to do what they like.

However, we have many examples of wanting to send a specific bit of 
reachability to X, and not allowing them to send it further along. So, 
this example falls through.

:-)

Russ

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

---

From: Stefan Mink <[email-masked]>
Date: Mon, 26 Sep 2005 14:25:06 +0200

Hi Sandy,

> Of course there is.  Sending the UPDATE *is* authorization to

on protocol level: yes
on business level: only AS-internally. It is covered by contracts
to which other parts of the Internet a _route_ (there is no
"propagating updates") may be propagated.

> sending the message authorizes them to do what they like.

that example doesn't make it law ;)
counter-example: digital media. If you are authorized to watch
a movie, that doesn't mean you are allowed to replicate it and
distribute it to whomever you like. At least there is a considerable
number of companies who would very like to make that impossible
and are working on that. I don't say it's directly transferable
to routing, but I see parallels...

> not party to that negotiation or carries any state representing

where is the difference between the data used to verify
the authorization of a route origination and the data used
to verify the redistribution authorization? Both are meta
data sets...

> something, it can be propagated.

as meantioned: that is the technical level

   tschuess
             Stefan
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec