RE: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Adam Thompson]

> -Original Message-
> From: NANOG  On
> Behalf Of Joe Maimon
> Sent: Thursday, March 31, 2022 6:20 PM
> Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255
> times
>
> [...]
> I think more and perhaps different knobs were and still are needed.

YES.  YESYESYES.

Having said that, I am currently able to express my local traffic policies 
(roughly 1/3 due to one particular upstream hamstrung by their parent company, 
1/3 due to NREN, 1/3 due to local IXP) using prepends of no more than +2 (both 
outbound and inbound, which I gather might be somewhat unusual).  That includes 
dealing with a "special" issue because both my local NREN RAN and I are both 
connected to the local IXP, and to a mutual downstream, which produces an 
interesting double-triangle topology, and this topology produces surprising 
emergent behaviours that I haven't seen described anywhere.

Prior to some reorganization (and several compromises) I needed +5 on both 
inbound and outbound (usually not at the same time) to adequately steer normal 
traffic.


Prepending is, IMHO literally, the abuse of a mechanism not initially designed 
to express complex policies.  It's a 1-dimensional tool in a space that really 
needs a 2- or 3-dimensional tool.

LOCAL_PREF is not useful for me and my upstreams, downstreams and peers: I have 
not yet found a scenario where it fixes any of my problems without creating 
even greater ones.  My traffic-steering issues ~all exist n>3 hops away, not 
directly with my BGP peers.

So prepending remains the only useful, usable knob I have.  And it's not a 
great knob for this, which I think might be the one thing everyone here can 
agree on!


> through nowadays, how about a long call back to each AS in the path

I'm not really loving that solution more than prepends, but at least it's 
something different?


> Would be nice to be able to publish your community scheme as simply
> conforming with RFCX and the to configure peers with process-rfcX
> statement and be mostly done.

That's a LONG way off!  Not that any other solution isn't equally far off, 
so...   Gotta start somewhere, I guess!

I don't have any better suggestions, other than I wish the LOCAL_PREF crowd 
could understand that it doesn't solve all the world's problems.  (Neither of 
my commercial upstreams currently admit to supporting communities that control 
it, anyway!)


Frustrated at the state of the world today,
-Adam

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Maimon]

Matthew Petach wrote:




Unfortunately, the reason crazy-long prepends actually propagate so
widely in the internet core is because most of those decisions to prefer
your peer's customers are done using a relatively big and heavy hammer.


IOW if your peer or customer has prepended 5 times or more, dont 
LOCAL_PREF or maybe even de-LOCAL_PREF it





For the most part--if you think LOCAL_PREF is the right knob to use 
for moving
traffic, it probably means you need to go back and rethink your 
traffic engineering

approach.   ^_^;

Matt


I think more and perhaps different knobs were and still are needed.

Here is an idea, as part of the all extra processing updates have to go 
through nowadays, how about a long call back to each AS in the path 
using some sort of standardized service, perhaps published via DNS, sort 
of an automated looking glass results compared to update-out. And then 
the receiver, however many AS's away starts to get a much clearer 
picture of the intent all the through and maybe perhaps some much better 
intelligent automated properly reactive internet wide traffic 
engineering standards will emerge.


Until then I think a slew of standardized communities that elicit near 
universal and predictable standard reactions is probably the best bet. 
The problem is that shifting too much control to the advertiser makes it 
a non-starter from the point of view of the receiver, and then you can 
forget about deployment.


Would be nice to be able to publish your community scheme as simply 
conforming with RFCX and the to configure peers with process-rfcX 
statement and be mostly done.


Joe

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Matthew Petach]

On Thu, Mar 31, 2022 at 3:16 PM Joe Maimon  wrote:

>
>
> Joe Provo wrote:
> > On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:
> >> :) probably the longest prepend in the world.
> >>
> >> A thought though, is it breaking any standard or best practice
> procedures?
> >
> > That said, prepending pretty much anything more than your current view
> > of the Internet's diameter in ASNs is useless in practice. Cascading
> > effects are considered in
> > https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
> > where a decent low number (5) is propsed.
> >
> > Chers,
> >
> > Joe
> >
>
> So is there a good way to signal along with a BGP route that the
> originator of the route wants you to know that this route has very high
> suckage factor and even if you normally prefer your peers customers
> whatever, you should perhaps think twice about that for this route,
> cause its really last resort.
>
> Because as-path is an overloaded multimeaning traffic influencing hammer
> that has imprecise and frequently undesirable results. And if that were
> not the case, than discussions of its relative size compared to internet
> diameter would be much more relevant.
>
> Joe
>
>
Unfortunately, the reason crazy-long prepends actually propagate so
widely in the internet core is because most of those decisions to prefer
your peer's customers are done using a relatively big and heavy hammer.

LOCAL_PREF is, in my opinion, the wrong tool to use, but it's what most
of the networks out there seem to have settled on, to the point of having
published BGP communities to use for controlling the LOCAL_PREF setting
on received routes: https://onestep.net/communities/

I've long practiced, and advocated for, the use of MEDs or tweaking origin
codes as a better way to nudge traffic towards customers, peers, customers
of peers, etc., because it still allows as-path to be a factor in nudging
traffic
away.   Prepend inbound 3 times on routes learned from your transit
provider,
but not on your peers, listen to MEDs from your peers, and enable
always-compare-med
and deterministic-med to allow values to be compared across different
pathways.

That way, someone trying to say "don't use this path" can do a simple
triple-prepend,
and see their traffic shift.  In our current world of using LOCAL_PREF,
however, the
poor customer keeps prepending more and more, and never sees their traffic
shift.
In desperation, they prepend the maximum number of times allowed, hoping
that
maybe this will somehow do the trick...not understanding that no matter
what they
do in the prepend realm, so long as their upstreams are using the
LOCAL_PREF
hammer, their prepends will fall on deaf ears.

For the most part--if you think LOCAL_PREF is the right knob to use for
moving
traffic, it probably means you need to go back and rethink your traffic
engineering
approach.   ^_^;

Matt

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Maimon]

Joe Provo wrote:

On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:

:) probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?


That said, prepending pretty much anything more than your current view
of the Internet's diameter in ASNs is useless in practice. Cascading
effects are considered in
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
where a decent low number (5) is propsed.

Chers,

Joe
  


So is there a good way to signal along with a BGP route that the 
originator of the route wants you to know that this route has very high 
suckage factor and even if you normally prefer your peers customers 
whatever, you should perhaps think twice about that for this route, 
cause its really last resort.


Because as-path is an overloaded multimeaning traffic influencing hammer 
that has imprecise and frequently undesirable results. And if that were 
not the case, than discussions of its relative size compared to internet 
diameter would be much more relevant.


Joe

RE: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Adam Thompson]

d?  Or the 519 at 11?  Remember, those are already the de-prepended 
paths.  I don’t want to have to police the RIB that tightly, deciding which 
routes I will and won’t accept and adjusting the limit periodically.

Unless your intent is to eliminate prepend-based traffic engineering from the 
internet altogether, which case 10 is a perfectly reasonable choice, but in the 
absence of any other globally-usable tool/knob, that’s a hill I WILL die on.

If there’s broad consensus that a path length limit is a good thing, I would 
suggest a value of no less than 32, based on the data I’ve got in my RIB right 
now.  I think, based only on random sampling of longer AS paths in my RIB, that 
32 would still give operators the latitude to perform AS-path-based traffic 
engineering at origin, during transit, and locally upon receipt, without routes 
getting inexplicably blackholed anywhere.

I’ve heard tonight that a path length limit of 32 is already commonly 
implemented.  Regardless of whether I think that’s a good idea, the spectre of 
the stack-breakingly-long path seems to be already mitigated in many places, 
but perhaps not widely?

To sum up, Tom’s conclusions as expressed in his email (below) may be 
qualitatively correct, but they are quantitatively wrong, at least on the 
matter of the numeric threshold.  And… I don’t really want to be the next 
Sprint(?) in BGP history just to protect myself from newbies on Mikrotiks[1], 
do you?

-Adam


[1] and others, yes, I know it’s not purely a Mikrotik issue.


Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: Tom Beecher 
Sent: Saturday, March 26, 2022 11:35 AM
To: Adam Thompson 
Cc: Paschal Masha ; nanog 
Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

Mostly what Matt said. ( I should have also said 'ride the 0/0 train INTO the 
DFZ, my mistake.)

Essentially, if ASN X is announcing a prefix with an excessive number of 
prepends, they are saying to the world 'This path exists , but it is hot 
garbage.' I'm more than happy to oblige those instructions and just drop that 
announcement completely. If ASN X announces that prefix with a reasonable 
number of prepends, happy to take it and use it.

If I get a prefix with an as-path longer than 10, (regardless of the state of 
prepends), I interpret that as :

1. They have made a mistake.
2. Someone else made a mistake.
3. They think that's a good idea, and have some things yet to learn. ( The old 
clue by four as Matt put it.)
4. It's malicious.
5. They actually are somehow more than 10 ASNs away from me. ( I don't even 
know if this is possible anymore without extreme effort. )

In any of those scenarios , I don't really care about optimized routing to that 
destination. Perfectly happy to just follow 0/0 to a DFZ upstream and let it go 
how it's going to go, or not. If there is a traffic impact such that an 
exception HAS to be made, that can be addressed as needed, but I can't think of 
a single circumstance I have hit where the correction involved accepting an 
obnoxiously long as_path announcement. ( I don't mean to imply none exist ; I'm 
sure someone has had to work though that. )

Maybe a length of 10 doesn't work for some environments and use cases, but I 
still am a firm believer that at a certain point, there is a length that 
becomes straight 'really don't care'.  I'd rather not discover a BGP 
implementation problem or acid trip memory pointer party by accepting 
announcements that are useless.







On Fri, Mar 25, 2022 at 5:56 PM Adam Thompson 
mailto:athomp...@merlin.mb.ca>> wrote:
Tom, how exactly does someone “ride the 0/0” train in the DFZ?

I’m connected to both commercial internet and NREN, and unfortunately-long 
paths are not uncommon in this scenario, in order to do traffic steering.  If 
there’s another solution that affects global inbound traffic distributions, I’d 
love to hear about it (and so would a lot of my peers in edu).

If there were a usable way to “dump” the excessively-long path only as long as 
a better path was already known by at least one edge router, that might be 
workable, but you’d have to keep track of it somewhere to reinstall it if the 
primary route went away… at which point you may as well have not dropped it in 
the first place.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG 
mailto:merlin.mb...@nanog.org>> 
On Behalf Of Tom Beecher
Sent: Friday, March 25, 2022 4:13 PM
To: Paschal Masha 

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Baldur Norddahl]

On Sun, 27 Mar 2022 at 18:31, Jon Lewis  wrote:

> Is prepending used for any purpose other than TE?  The point I think Joe
> was trying to make was prepending once or even a few times has uses.
> Prepending more than a few times is unlikely to accomplish anything a few
> prepends didn't get done.
>

I suppose so-called "backup routes" could also be called traffic
engineering yet it is different from the use case I described.

I understand the "diameter of the internet" to mean the maximum number of
unique AS numbers in an AS PATH observed in any route in my DFZ routing
table. Say I have two IP transit uplinks and I want one to be strictly
backup meaning I want to receive no traffic unless the other is down. I
might then prepend at least "the diameter of the internet" and that would
be enough. Any more prepends will do nothing. This could probably be proven
mathematically for the worst case, although in reality you would not even
need that many prepends to get the effect.

However using prepends for traffic engineering in the sense prioritizing my
peers relatively to each other is completely different. Especially true
when some are peers on internet exchanges (not IP transit). Here the
diameter of the internet is completely irrelevant. What matters is the
number of classes I can make up for my peers. I admit those two numbers
might not be all that different, but I feel it is still worth pointing out
the error in the logic.

The logic is wrong even for the backup case. Say I have an extreme of N x
IP transits and I want all of them to be backups in a strict order. Such
that all traffic comes in on transit A. If transit A is down, then
everything should use B. If A and B are down then 100% to C etc. In that
case I would need to prepend "the diameter of the internet" on B and "the
diameter of the internet" times two on C etc. Why times two and not + 1?
Because when A is down we have B with a number of prepends. C needs to have
"the diameter of the internet" more than B to be sure no traffic goes that
way when B is active.

Prepending 50, 100, 200+ times is kind of a universal "We have no clue
> what we're doing and you should reject our routes."
>

That is likely yes.

Regards,

Baldur

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Jon Lewis]

On Fri, 25 Mar 2022, Baldur Norddahl wrote:


On Fri, 25 Mar 2022 at 17:32, Joe Provo  wrote:
  That said, prepending pretty much anything more than your current view
  of the Internet's diameter in ASNs is useless in practice.


That is one way of viewing it. But prepending can also be used for traffic 
engineering. I could prepend 1
to my free peers, 2 to my paid peers, 3 to cheap ip transit, 4 to expensive ip 
transit etc. The linked
draft RFC does not appear to discuss this at all. The depth of prepending used 
this way only relates to how
many different classes of peers you can imagine in your setup and is not at all 
related to the "internet's
diameter".


Is prepending used for any purpose other than TE?  The point I think Joe 
was trying to make was prepending once or even a few times has uses. 
Prepending more than a few times is unlikely to accomplish anything a few 
prepends didn't get done.


Prepending 50, 100, 200+ times is kind of a universal "We have no clue 
what we're doing and you should reject our routes."


Once upon a time, such long prepends would break certain BGP 
implementations, causing session resets when a route like this was 
encountered.  Hopefully, that's not a problem anymore, but enough networks 
likely still block excessive prepends that you shouldn't expect to be able 
to do this and have your route globally accepted...just like you can't 
advertise a v4 /25 and expect global reachability if there are no covering 
aggregate advertisements.


The interesting question here is, "did they really think a few more 
prepends would get the job done?" or did they misunderstand their router's 
prepend function, prepend 21299 (thinking they were telling it to prepend 
their ASN), and that got truncated because the syntax was actually telling 
it how many times to prepend the local AS?  I'm guessing the latter, as 
they seem to have 254 prepends, and I'm guessing 255 is the max number of 
instances of their ASN their router is willing to put on an advertised 
route.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Tom Beecher]

Mostly what Matt said. ( I should have also said 'ride the 0/0 train INTO
the DFZ, my mistake.)

Essentially, if ASN X is announcing a prefix with an excessive number of
prepends, they are saying to the world 'This path exists , but it is hot
garbage.' I'm more than happy to oblige those instructions and just drop
that announcement completely. If ASN X announces that prefix with a
reasonable number of prepends, happy to take it and use it.

If I get a prefix with an as-path longer than 10, (regardless of the state
of prepends), I interpret that as :

1. They have made a mistake.
2. Someone else made a mistake.
3. They think that's a good idea, and have some things yet to learn. ( The
old clue by four as Matt put it.)
4. It's malicious.
5. They actually are somehow more than 10 ASNs away from me. ( I don't even
know if this is possible anymore without extreme effort. )

In any of those scenarios , I don't really care about optimized routing to
that destination. Perfectly happy to just follow 0/0 to a DFZ upstream and
let it go how it's going to go, or not. If there is a traffic impact such
that an exception HAS to be made, that can be addressed as needed, but I
can't think of a single circumstance I have hit where the correction
involved accepting an obnoxiously long as_path announcement. ( I don't mean
to imply none exist ; I'm sure someone has had to work though that. )

Maybe a length of 10 doesn't work for some environments and use cases, but
I still am a firm believer that at a certain point, there is a length that
becomes straight 'really don't care'.  I'd rather not discover a BGP
implementation problem or acid trip memory pointer party by accepting
announcements that are useless.







On Fri, Mar 25, 2022 at 5:56 PM Adam Thompson 
wrote:

> Tom, how exactly does someone “ride the 0/0” train in the DFZ?
>
>
>
> I’m connected to both commercial internet and NREN, and unfortunately-long
> paths are not uncommon in this scenario, in order to do traffic steering.
> If there’s another solution that affects global *inbound* traffic
> distributions, I’d love to hear about it (and so would a lot of my peers in
> edu).
>
>
>
> If there were a usable way to “dump” the excessively-long path only as
> long as a better path was already known by at least one edge router, that
> might be workable, but you’d have to keep track of it somewhere to
> reinstall it if the primary route went away… at which point you may as well
> have not dropped it in the first place.
>
>
>
> -Adam
>
>
>
> *Adam Thompson*
> Consultant, Infrastructure Services
> [image: MERLIN]
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>
>
>
> *From:* NANOG  *On Behalf
> Of *Tom Beecher
> *Sent:* Friday, March 25, 2022 4:13 PM
> *To:* Paschal Masha 
> *Cc:* nanog 
> *Subject:* Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255
> times
>
>
>
> The best practice with regards to as_path length is to have an edge filter
> that dumps any prefix with a length longer than say 10. Depending on the
> situation, might even be able to go smaller.
>
>
>
> At a certain point, keeping that route around does nothing for you, just
> shoot it and ride the 0/0 train.
>
>
>
> On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha <
> paschal.ma...@ke.wananchi.com> wrote:
>
> :) probably the longest prepend in the world.
>
> A thought though, is it breaking any standard or best practice procedures?
>
> Regards
> Paschal Masha | Engineering
> Skype ID: paschal.masha
>
> - Original Message -
> From: "Erik Sundberg" 
> To: "nanog" 
> Sent: Friday, March 25, 2022 6:43:38 AM
> Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
>
> If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends
> for 46.42.196.0/24 from 255 prepends to a more reasonable number of
> prepends let's say 20. Thanks!
>
> This is a Kazakhstan register IP Block and ASN
>
>
>
> Network Next Hop Metric LocPrf Weight Path
>
> *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 2

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Matthew Petach]

On Fri, Mar 25, 2022 at 6:19 PM Amir Herzberg  wrote:

> Hi Matthew and NANOG,
>
> I don't want to defend prepending 255 times, and can understand filtering
> of extra-prepended-announcements, but I think Matthew may not be correct
> here:
>
>> Anyone that is prepending to do traffic engineering is
>> doing *differential* prepending; that is, a longer number
>> of prepends along one path, with a shorter set of prepends
>> along a different path.
>>
>> So, dropping the inbound announcement with 255 prepends
>> merely means your router will look for the advertisement with
>> a shorter number of prepends on it.
>>
>
> Right. But let's consider the (typical) case where someone is prepending
> for traffic engineering. Now, if you're not very near to the origin of the
> prepended announcement, and still received it (and not the shorter
> alternative), then it is quite likely that you received it since the
> alternate path failed - and the backup path was announced, instead (by
> upstreams of the origin). So your router is quite likely not to receive the
> shorter announcement.
>
>
Note that as-path prepending only matters as a *differential* value.

Choosing between 5 and 8 prepends, for example, gives you 3 levels of
differentiation between the paths.

Prepending 255 times is equivalent to setting MAXCOST in OSPF; it's an
overload setting, saying "don't freaking use this path *EVER*".

If you want to traffic engineer, you set your less preferred path with
say 5 prepends, and your more preferred path with 3 prepends, and
your really really preferred path with 1 prepend.

If you're setting 255 prepends on a path, that's not traffic engineering,
that's equivalent to setting the overload bit; it's the maximum metric
equivalent in a link-state routing protocol.  It's clearly a DO-NOT-USE
indicator, in the same category as community 0xFF04 or
65535:0

In short--if someone sends me 255 prepends, it's going to
be treated the same way as LSInfinity in OSPF.

Matt



> After all, if your router received both short and long announcements (from
> same relationship, e.g., both from providers), then your router would
> probably select the shorter path anyway, without need to filter out the
> long one, right?
>
> So, filtering announcements with many prepends may cause you to lose
> connectivity to these networks. Of course, you may not mind losing
> connectivity to Kazakhstan :) ...
>
> best, Amir
>
>>
>>
>> --
> Amir Herzberg
>
> Comcast professor of Security Innovations, Computer Science and
> Engineering, University of Connecticut
> Homepage: https://sites.google.com/site/amirherzberg/home
> `Applied Introduction to Cryptography' textbook and lectures:
>  https://sites.google.com/site/amirherzberg/applied-crypto-textbook
> 
>
>
>
>
> On Fri, Mar 25, 2022 at 8:19 PM Matthew Petach 
> wrote:
>
>>
>>
>> On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson 
>> wrote:
>>
>>> Tom, how exactly does someone “ride the 0/0” train in the DFZ?
>>>
>>
>> It's not so much "ride the 0/0 train" as much as it is
>> "treat excessive prepends as network-unreachable"
>>
>> Think of prepends beyond say 10 prepends as a way
>> to signal "infinite" distance--essentially, "unreachable"
>> for that prefix along that path.
>>
>> Anyone that is prepending to do traffic engineering is
>> doing *differential* prepending; that is, a longer number
>> of prepends along one path, with a shorter set of prepends
>> along a different path.
>>
>> So, dropping the inbound announcement with 255 prepends
>> merely means your router will look for the advertisement with
>> a shorter number of prepends on it.
>>
>> If you're only announcing one path for your prefix, and it is
>> prepended 255 times, you're fundamentally not understanding
>> how BGP works, and the only way to get a clue-by-four might
>> be to discover you've made your prefix invisible to a significant
>> portion of the internet.
>>
>>
>>>
>>>
>>> I’m connected to both commercial internet and NREN, and
>>> unfortunately-long paths are not uncommon in this scenario, in order to do
>>> traffic steering.  If there’s another solution that affects global
>>> *inbound* traffic distributions, I’d love to hear about it (and so
>>> would a lot of my peers in edu).
>>>
>>>
>>>
>>> If there were a usable way to “dump” the excessively-long path only as
>>> long as a better path was already known by at least one edge router, that
>>> might be workable, but you’d have to keep track of it somewhere to
>>> reinstall it if the primary route went away… at which point you may as well
>>> have not dropped it in the first place.
>>>
>>>
>> You dump the excessively-long path based on the assumption that
>> the only reason for a long set of prepends out one path is to shift
>> traffic
>> away from that path to one that you're advertising out with a *shorter*
>> set of prepends.
>>
>> The router doesn't need to 'look' for or 'keep track' of the different
>> p

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Amir Herzberg]

Hi Matthew and NANOG,

I don't want to defend prepending 255 times, and can understand filtering
of extra-prepended-announcements, but I think Matthew may not be correct
here:

> Anyone that is prepending to do traffic engineering is
> doing *differential* prepending; that is, a longer number
> of prepends along one path, with a shorter set of prepends
> along a different path.
>
> So, dropping the inbound announcement with 255 prepends
> merely means your router will look for the advertisement with
> a shorter number of prepends on it.
>

Right. But let's consider the (typical) case where someone is prepending
for traffic engineering. Now, if you're not very near to the origin of the
prepended announcement, and still received it (and not the shorter
alternative), then it is quite likely that you received it since the
alternate path failed - and the backup path was announced, instead (by
upstreams of the origin). So your router is quite likely not to receive the
shorter announcement.

After all, if your router received both short and long announcements (from
same relationship, e.g., both from providers), then your router would
probably select the shorter path anyway, without need to filter out the
long one, right?

So, filtering announcements with many prepends may cause you to lose
connectivity to these networks. Of course, you may not mind losing
connectivity to Kazakhstan :) ...

best, Amir

>
>
> --
Amir Herzberg

Comcast professor of Security Innovations, Computer Science and
Engineering, University of Connecticut
Homepage: https://sites.google.com/site/amirherzberg/home
`Applied Introduction to Cryptography' textbook and lectures:
 https://sites.google.com/site/amirherzberg/applied-crypto-textbook





On Fri, Mar 25, 2022 at 8:19 PM Matthew Petach 
wrote:

>
>
> On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson 
> wrote:
>
>> Tom, how exactly does someone “ride the 0/0” train in the DFZ?
>>
>
> It's not so much "ride the 0/0 train" as much as it is
> "treat excessive prepends as network-unreachable"
>
> Think of prepends beyond say 10 prepends as a way
> to signal "infinite" distance--essentially, "unreachable"
> for that prefix along that path.
>
> Anyone that is prepending to do traffic engineering is
> doing *differential* prepending; that is, a longer number
> of prepends along one path, with a shorter set of prepends
> along a different path.
>
> So, dropping the inbound announcement with 255 prepends
> merely means your router will look for the advertisement with
> a shorter number of prepends on it.
>
> If you're only announcing one path for your prefix, and it is
> prepended 255 times, you're fundamentally not understanding
> how BGP works, and the only way to get a clue-by-four might
> be to discover you've made your prefix invisible to a significant
> portion of the internet.
>
>
>>
>>
>> I’m connected to both commercial internet and NREN, and
>> unfortunately-long paths are not uncommon in this scenario, in order to do
>> traffic steering.  If there’s another solution that affects global
>> *inbound* traffic distributions, I’d love to hear about it (and so would
>> a lot of my peers in edu).
>>
>>
>>
>> If there were a usable way to “dump” the excessively-long path only as
>> long as a better path was already known by at least one edge router, that
>> might be workable, but you’d have to keep track of it somewhere to
>> reinstall it if the primary route went away… at which point you may as well
>> have not dropped it in the first place.
>>
>>
> You dump the excessively-long path based on the assumption that
> the only reason for a long set of prepends out one path is to shift
> traffic
> away from that path to one that you're advertising out with a *shorter*
> set of prepends.
>
> The router doesn't need to 'look' for or 'keep track' of the different
> path; the human makes the decision that any sane BGP speaker
> would only prepend 255 times on a path if there was a shorter
> as-path advertisement they wanted people to use instead.
>
> So, drop the excessively long prepended path, and make use
> of the 'should be in the table somewhere' advertisement of the
> prefix with fewer prepends.
>
> Easy-peasy.
>
>
>>
>>
>> -Adam
>>
>>
>>

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Matthew Petach]

On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson 
wrote:

> Tom, how exactly does someone “ride the 0/0” train in the DFZ?
>

It's not so much "ride the 0/0 train" as much as it is
"treat excessive prepends as network-unreachable"

Think of prepends beyond say 10 prepends as a way
to signal "infinite" distance--essentially, "unreachable"
for that prefix along that path.

Anyone that is prepending to do traffic engineering is
doing *differential* prepending; that is, a longer number
of prepends along one path, with a shorter set of prepends
along a different path.

So, dropping the inbound announcement with 255 prepends
merely means your router will look for the advertisement with
a shorter number of prepends on it.

If you're only announcing one path for your prefix, and it is
prepended 255 times, you're fundamentally not understanding
how BGP works, and the only way to get a clue-by-four might
be to discover you've made your prefix invisible to a significant
portion of the internet.


>
>
> I’m connected to both commercial internet and NREN, and unfortunately-long
> paths are not uncommon in this scenario, in order to do traffic steering.
> If there’s another solution that affects global *inbound* traffic
> distributions, I’d love to hear about it (and so would a lot of my peers in
> edu).
>
>
>
> If there were a usable way to “dump” the excessively-long path only as
> long as a better path was already known by at least one edge router, that
> might be workable, but you’d have to keep track of it somewhere to
> reinstall it if the primary route went away… at which point you may as well
> have not dropped it in the first place.
>
>
You dump the excessively-long path based on the assumption that
the only reason for a long set of prepends out one path is to shift traffic
away from that path to one that you're advertising out with a *shorter*
set of prepends.

The router doesn't need to 'look' for or 'keep track' of the different
path; the human makes the decision that any sane BGP speaker
would only prepend 255 times on a path if there was a shorter
as-path advertisement they wanted people to use instead.

So, drop the excessively long prepended path, and make use
of the 'should be in the table somewhere' advertisement of the
prefix with fewer prepends.

Easy-peasy.


>
>
> -Adam
>
>
>

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Brian Knight via NANOG]

Ask your upstream providers for a BGP community tag that lowers localpref below 
100 within their network. Set that community tag on any backup routes along 
with your (moderate) path prepending.

The backup upstream will then install that route only if there is no other way 
to get to your AS.

The path prepending remains so that other providers can more quickly install 
the primary route when it comes back.

Those two actions together have always made any backup route behave correctly 
for me.

-Brian

> On Mar 25, 2022, at 4:57 PM, Adam Thompson  wrote:
> 
> 
> Tom, how exactly does someone “ride the 0/0” train in the DFZ?
>  
> I’m connected to both commercial internet and NREN, and unfortunately-long 
> paths are not uncommon in this scenario, in order to do traffic steering.  If 
> there’s another solution that affects global inbound traffic distributions, 
> I’d love to hear about it (and so would a lot of my peers in edu).
>  
> If there were a usable way to “dump” the excessively-long path only as long 
> as a better path was already known by at least one edge router, that might be 
> workable, but you’d have to keep track of it somewhere to reinstall it if the 
> primary route went away… at which point you may as well have not dropped it 
> in the first place.
>  
> -Adam
>  
> Adam Thompson
> Consultant, Infrastructure Services
> 
> 100 - 135 Innovation Drive
> Winnipeg, MB, R3T 6A8
> (204) 977-6824 or 1-800-430-6404 (MB only)
> athomp...@merlin.mb.ca
> www.merlin.mb.ca
>  
> From: NANOG  On Behalf Of Tom 
> Beecher
> Sent: Friday, March 25, 2022 4:13 PM
> To: Paschal Masha 
> Cc: nanog 
> Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
>  
> The best practice with regards to as_path length is to have an edge filter 
> that dumps any prefix with a length longer than say 10. Depending on the 
> situation, might even be able to go smaller. 
>  
> At a certain point, keeping that route around does nothing for you, just 
> shoot it and ride the 0/0 train. 
>  
> On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha  
> wrote:
> :) probably the longest prepend in the world.
> 
> A thought though, is it breaking any standard or best practice procedures?
> 
> Regards 
> Paschal Masha | Engineering 
> Skype ID: paschal.masha
> 
> ----- Original Message -----
> From: "Erik Sundberg" 
> To: "nanog" 
> Sent: Friday, March 25, 2022 6:43:38 AM
> Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
> 
> If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends 
> for 46.42.196.0/24 from 255 prepends to a more reasonable number of prepends 
> let's say 20. Thanks! 
> 
> This is a Kazakhstan register IP Block and ASN 
> 
> 
> 
> Network Next Hop Metric LocPrf Weight Path 
> 
> *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21 299 21299 21299 21299 21299 21299 21299 21299 
> 21299 21299 21299 21299 21299 21299 i 
> 
> 
> 
> 
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
> previous e-mail messages attached to it may contain confidential information 
> that is legally privileged. If you are not the 

RE: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Adam Thompson]

Tom, how exactly does someone “ride the 0/0” train in the DFZ?

I’m connected to both commercial internet and NREN, and unfortunately-long 
paths are not uncommon in this scenario, in order to do traffic steering.  If 
there’s another solution that affects global inbound traffic distributions, I’d 
love to hear about it (and so would a lot of my peers in edu).

If there were a usable way to “dump” the excessively-long path only as long as 
a better path was already known by at least one edge router, that might be 
workable, but you’d have to keep track of it somewhere to reinstall it if the 
primary route went away… at which point you may as well have not dropped it in 
the first place.

-Adam

Adam Thompson
Consultant, Infrastructure Services
[MERLIN]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca<mailto:athomp...@merlin.mb.ca>
www.merlin.mb.ca<http://www.merlin.mb.ca/>

From: NANOG  On Behalf Of Tom 
Beecher
Sent: Friday, March 25, 2022 4:13 PM
To: Paschal Masha 
Cc: nanog 
Subject: Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

The best practice with regards to as_path length is to have an edge filter that 
dumps any prefix with a length longer than say 10. Depending on the situation, 
might even be able to go smaller.

At a certain point, keeping that route around does nothing for you, just shoot 
it and ride the 0/0 train.

On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha 
mailto:paschal.ma...@ke.wananchi.com>> wrote:
:) probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?

Regards
Paschal Masha | Engineering
Skype ID: paschal.masha

- Original Message -
From: "Erik Sundberg" mailto:esundb...@nitelusa.com>>
To: "nanog" mailto:nanog@nanog.org>>
Sent: Friday, March 25, 2022 6:43:38 AM
Subject: DMARC ViolationAS21299 - 46.42.196.0/24<http://46.42.196.0/24> ASN 
prepending 255 times

If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 
46.42.196.0/24<http://46.42.196.0/24> from 255 prepends to a more reasonable 
number of prepends let's say 20. Thanks!

This is a Kazakhstan register IP Block and ASN



Network Next Hop Metric LocPrf Weight Path

*> 46.42.196.0/24<http://46.42.196.0/24> x.x.x.x 0 100 0 2914 174 3216 3216 
35168 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21 299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 i








CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner.
Thank you.

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Tom Beecher]

The best practice with regards to as_path length is to have an edge filter
that dumps any prefix with a length longer than say 10. Depending on the
situation, might even be able to go smaller.

At a certain point, keeping that route around does nothing for you, just
shoot it and ride the 0/0 train.

On Fri, Mar 25, 2022 at 4:09 AM Paschal Masha 
wrote:

> :) probably the longest prepend in the world.
>
> A thought though, is it breaking any standard or best practice procedures?
>
> Regards
> Paschal Masha | Engineering
> Skype ID: paschal.masha
>
> - Original Message -
> From: "Erik Sundberg" 
> To: "nanog" 
> Sent: Friday, March 25, 2022 6:43:38 AM
> Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times
>
> If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends
> for 46.42.196.0/24 from 255 prepends to a more reasonable number of
> prepends let's say 20. Thanks!
>
> This is a Kazakhstan register IP Block and ASN
>
>
>
> Network Next Hop Metric LocPrf Weight Path
>
> *> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21 299
> 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299
> 21299 i
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files
> or previous e-mail messages attached to it may contain confidential
> information that is legally privileged. If you are not the intended
> recipient, or a person responsible for delivering it to the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution or use of any of the information contained in or attached to
> this transmission is STRICTLY PROHIBITED. If you have received this
> transmission in error please notify the sender immediately by replying to
> this e-mail. You must destroy the original transmission and its attachments
> without reading or saving in any manner.
> Thank you.
>
>
>
>

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Baldur Norddahl]

On Fri, 25 Mar 2022 at 17:32, Joe Provo  wrote:

> That said, prepending pretty much anything more than your current view
> of the Internet's diameter in ASNs is useless in practice.
>

That is one way of viewing it. But prepending can also be used for traffic
engineering. I could prepend 1 to my free peers, 2 to my paid peers, 3 to
cheap ip transit, 4 to expensive ip transit etc. The linked draft RFC does
not appear to discuss this at all. The depth of prepending used this way
only relates to how many different classes of peers you can imagine in your
setup and is not at all related to the "internet's diameter".

To someone on the other side of the planet, who are neither peers nor
customers of peers, they will just observe that I am prepending 3 or 4
times and wondering why the extra prepends? The answer is that closer to my
home there are people who are observing the same routes with 1 or 2
prepends and that it matters.

The draft RFC lists some alternatives to prepends of which none can do
anything of the sort I just described.

Regards,

Baldur

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Joe Provo]

On Fri, Mar 25, 2022 at 11:08:01AM +0300, Paschal Masha wrote:
> :) probably the longest prepend in the world.
> 
> A thought though, is it breaking any standard or best practice procedures?

Many popular BGP implementations have historically had weaknesses 
with excessively long AS-paths. Best practice is to protect ones'
infrastructure so many networks drop paths over certain lengths
(at various times, 50 or 100 were common due to specific issues).
It is highly common for any filtering mechanism, once established,
to stay in place, so I fully expect this path to be invible to many
and fragile for the rest [see
https://blog.apnic.net/2019/07/15/excessive-bgp-as-path-prepending-is-a-self-inflicted-vulnerability/].

That said, prepending pretty much anything more than your current view
of the Internet's diameter in ASNs is useless in practice. Cascading
effects are considered in 
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/
where a decent low number (5) is propsed.

Chers,

Joe
 
-- 
Posted from my personal account - see X-Disclaimer header.
Joe Provo / Gweep / Earthling 

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Bjørn Mork]

Paschal Masha  writes:

> :) probably the longest prepend in the world.
>
> A thought though, is it breaking any standard or best practice procedures?

Don't think so.  But there is this draft suggesting max 5:
https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/


Bjørn

Re: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

[Paschal Masha]

:) probably the longest prepend in the world.

A thought though, is it breaking any standard or best practice procedures?

Regards 
Paschal Masha | Engineering 
Skype ID: paschal.masha

- Original Message -
From: "Erik Sundberg" 
To: "nanog" 
Sent: Friday, March 25, 2022 6:43:38 AM
Subject: DMARC ViolationAS21299 - 46.42.196.0/24 ASN prepending 255 times

If anyone from AS21299 is lurking on Nanog. Please reduce your AS prepends for 
46.42.196.0/24 from 255 prepends to a more reasonable number of prepends let's 
say 20. Thanks! 

This is a Kazakhstan register IP Block and ASN 



Network Next Hop Metric LocPrf Weight Path 

*> 46.42.196.0/24 x.x.x.x 0 100 0 2914 174 3216 3216 35168 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21 299 21299 21299 21299 21299 21299 21299 21299 21299 
21299 21299 21299 21299 21299 i 








CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner. 
Thank you.