Subject: Re: [RPSEC] issue: operator use

From: Sandy Murphy <[email-masked]>
Date: Thu, 10 Mar 2005 11:40:01 -0500 (EST)

>>have built a business model around gathering small customers, aggregating
>>them, then announcing all those routes sans AS to make it appear for the
>>customers that they are direct customers of us or anyone else the
>>middleman AS is connected to. Do these guys need to come up with a new
>>business model? Or will there be provisions for a model like this?
>>
>>Guy
>
>Guy,
>
>I think an essential part of any BGP security solution will be a
>facility that enables each prefix holder to authorize one or more
>ASes to originate the prefixes of that holder. With such a facility
>in place, it would be OK for your customers to authorize you to
>originate their prefixes. This accommodates the business model you
>described, yet it prevents any AS that the prefix holders did not
>authorized from being able to originate the prefixes, without
>detection.

This presumes that GX's aggregating customer is telling their clients
who they might be served through.  The client has to sign an authorization
for "anyone else the middleman AS is connected to".

On another point - one of the requirements in the draft says that
your peer's AS has to be on the end of the AS_PATH you receive.
That check would fail on the updates GS receives from its
aggregating customer because the customer is explicitly
leaving off its AS.

--Sandy

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

---

From: Doug Montgomery <[email-masked]>
Date: Thu, 10 Mar 2005 12:11:21 -0500

In a GROW discussion (on another topic) it sounds as if prepending other
ASes for the purpose of effecting downstream distribution policy (i.e.,
poisoning) is a  common "technique".

While one may want to detect malicious uses of this technique (maybe all
uses are malicious is some AS's view ;^) it would seem that any technique
that would allow one to verify who added what to the PATH, would also
potentially invalidate this technique.

Not clear if this is good or bad ... but just something to keep in mind
in this discussion.

dougm

---

From: Guy Tal <[email-masked]>
Date: Thu, 10 Mar 2005 12:45:05 -0500 (EST)

> for "anyone else the middleman AS is connected to".

Correct, the end customer can sign up to receive just GX routes, just UU
routes, whatever they want.

> aggregating customer because the customer is explicitly

Right. So just to be clear, this draft is basically requiring, among
other things, that enforce-first-AS be actually enforced, correct?

Guy

---

From: Russ White <[email-masked]>
Date: Thu, 10 Mar 2005 13:46:28 -0500 (Eastern Standard Time)

>> On another point - one of the requirements in the draft says that your 
>> peer's AS has to be on the end of the AS_PATH you receive. That check 
>> would fail on the updates GS receives from its aggregating customer 
>> because the customer is explicitly leaving off its AS.
>

Yes.... No security mechanism thus far proposed (S-BGP, soBGP, IRV, SPV, 
etc) will actually work without it.... It seems logically impossible to 
actually enforce any security at all if the AS of your peer isn't the AS 
they place in the path when they send an update to you.

BTW, we do need exceptions to this rule for AS Transition situations, but 
I'm not certain how to actually word such exceptions, or if we could leave 
them as a "local matter," and thus, not worth worrying about (?).... We 
probably need some operator input on this.

:-)

Russ

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

---

From: Stefan Mink <[email-masked]>
Date: Fri, 18 Mar 2005 00:11:38 +0100

Hi Doug,

> Not clear if this is good or bad ... but just something to keep in mind

this is again a sign of how the AS-Path currently gets (mis)used
due to missing alternatives:

* AS-path prependings: missing other equivalent TE features of BGP
* AS-path poisoning: missing authorization schemes

It is similar with communities: every missing feature of BGP
somehow gets implemented via communities these days.

It just seems BGP is not powerful enough but can be tweaked
in so many ways that it can do what you want. An interesting
example who you can mess up things equally is demonstrated on
http://www.tm.uka.de/idrws/2004/contributions/IDRWS2004--22--Griffin_Tim--BGP_Wegdies_Bad_Policy_Interactions_that_cannot_be_debugged.pdf

Exactly that tweaking is what makes BGP a pain to secure.
I wonder if this would be any different if there would be
"regular" routing protocol elements to replace the tweakings...

    tschuess
              Stefan

PS: <publicity>
      IDRWS will take place in May in Stockholm and aims
      at filling one day with security relevant talks:
      http://www.tm.uka.de/idrws/cfc.php
     </publicity>

--
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