Re: Proxying NetFlow traffic correctly

[Jérôme Fleury]

We use pmacct with it's tee plugin - it gets the job done beautifully and
it's a one-liner config.

https://github.com/pmacct/pmacct/blob/master/CONFIG-KEYS

On Tue, Jun 6, 2017 at 2:43 PM, Sami via NANOG  wrote:

> Hello,
> I have been searching for a solution that collects/duplicates NetFlow
> traffic properly for a while but i couldn't find any.
> Do you know any good unix alternative to ntopng, flowd, flow-tools?
>
> nprobe of netflow seems to be the closest one to fit my needs but i want
> to see if there are any other solution.
>
> My goal is to centralize NetFlow traffic into a single machine and then
> proxy some flows to other destinations for further analysis
>
> Best Regards,
> Sami

Re: Templating/automating configuration

[Andrew Dampf]

Salt is great for generating configs based on jinja templates, and you can
use napalm in conjunction with salt to push the configs to the device on a
set schedule (typically this is done hourly). If manual changes are made to
the router, salt would override them on the next run, so it's a great way
to make sure configs are consistent.


On Tue, Jun 6, 2017 at 9:25 AM Graham Johnston 
wrote:

> Short of complete SDN, for those of you that have some degree of
> configuration templating and/or automation tools what is it that you run?
> I'm envisioning some sort of tool that let's me define template snippets of
> configuration and aids in their deployment to devices. I'm okay doing the
> heaving lifting in defining everything, I'm just looking for the tool that
> stitches it together and hopefully makes things a little less error prone
> for those who aren't as adept.
>
> Graham Johnston
> Network Planner
> Westman Communications Group
> 204.717.2829 <(204)%20717-2829>
> johnst...@westmancom.com
>
>

Re: DMCA processing software

[Eric Kuhnke]

Now new and improved for the modern era:

https://devnull-as-a-service.com/home/


On Tue, Jun 6, 2017 at 10:30 PM, Tony Wicks  wrote:

> Speaking for Networks outside of the USA (and not being at all helpful
> sorry), /dev/null works well. Sorry, couldn't help myself...
>
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jason Baugher
> Sent: Wednesday, 7 June 2017 5:18 PM
> To: NANOG 
> Subject: DMCA processing software
>
> I'm curious what people are using to manage DMCA takedown notices in
> mid-sized networks. I've been searching, and have found the ACNS spec, and
> a few obscure references to an RT plugin, but not much else. As the ISP I
> work for grows, manual handling of notices is starting to be a problem. I'd
> prefer something open-source so we can extend it to hook into our other
> systems, but primarily I need something to parse the notice emails, store
> the information, track the number of incidents over time, and generate
> letters to users.
>
> If nothing exists, and everyone just has in-house proprietary systems,
> then we'll start down the same road, but I don't like to re-invent the
> wheel if I can help it.
>
> Thanks
>
>

Re: IPv4 Hijacking For Idiots

[Robert L Mathews]

On 6/6/17 6:14 AM, Scott Christopher wrote:

> Or one could register aсme.com

For what it's worth, that domain name (with a Cyrillic character 0441
replacing the "c" in "acme") wouldn't be allowed based on this:

 
https://www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-policy/registration-rules/index.xhtml

(See section 3, "For example, a character from the Latin script cannot
be used in the same IDN with any Cyrillic character.")

But those rules are not foolproof. "асе.com" is entirely Cyrillic (0430
0441 0435), and is in fact registered. Compare these in Firefox:

 http://ace.com/
 http://асе.com/

Chrome has protection against this, displaying the latter as
"http://xn--80ak9a.com/; due to:

 https://www.xudongz.com/blog/2017/idn-phishing/

But it's all very much ad-hoc.


> (If the reader can't tell the difference between acme.com and aсme.com ,
> the reader is using one of the multitude of email clients and/or fonts
> that presents Unicode poorly.)

Even the Unicode sample glyph charts render code points 0063 and 0441
identically:

 http://www.unicode.org/charts/PDF/U.pdf
 http://www.unicode.org/charts/PDF/U0400.pdf

And there are lots of other examples. It's hard to say how to fix all
possible cases of what amounts to a human language problem.

-- 
Robert L Mathews

Re: Templating/automating configuration

[James Bensley]

On 7 June 2017 at 19:52, Brian Knight  wrote:
> The import process to the database runs directly on our rancid server, 
> reading the downloaded configs out of the appropriate directory within 
> rancid. Most of our gear is Cisco, so the ciscoconfparse module for Python 
> helps a lot with organizing and querying the config.  From there, the config 
> is parsed for key items like interface name, description, configured 
> bandwidth, etc., and that info is then added or updated as necessary in the 
> database.
>
>
>
> Because it's dependent on rancid, there is some lag time between when a 
> change is made and when the database gets updated, so we still strongly 
> encourage running the pre-config checks for new circuits.  But with PyEZ, it 
> looks like you easily could, after grabbing that lock, validate the existing 
> config before pushing down new config.  Lots of possibilities there.  I'm 
> envious that you have a vendor-written Python module as a choice!
...
>
> Or, at least, rebuild the existing configs based on the new source of truth, 
> so that subsequent config parsing conforms to a single standard.

Cisco IOS and IOS-XE have config locks on the CLI, as well as
automatic configuration rollbacks and the ability to generate a config
diff on deice. For some reason lots of people seem to forget/ignore
this.

If you are using NAPALM then I believe you can also implement this
through NAPALM.

Cheers,
James.

Re: Merit RADB support

[Andree Toonk]

Hi Chuck,

My secret spy satellite informs me that Chuck Anderson wrote On
2017-06-07, 5:21 PM:

> Apologies to Merit RADB, it was BGPmon that never responds.  Merit
> RADB actually does respond--my frustration is more about the
> difficulty in getting them to delete stale objects that others
> registered, although I was finally able to get my objects cleaned up.

Happy to look into this for you. We should (and normally do) follow-up
on all support requests (support @ bgpmon).

Regarding route objects:
BGPmon syncs twice a day with all IRRs for route objects. Route objects
that haven't been seen in the IRR for more than 48 hours are deleted
from our local database (cache so we don't hammer the IRR).

Could be a bug, happy to look into this but the issues doesn't
immediately ring a bell.

I'll reach out to you off-list as well to see what's going on.

Cheers
 Andree (BGPmon)

Re: Templating/automating configuration

[Brian Knight]

 On Wed, 07 Jun 2017 04:23:33 -0500 t...@pelican.org wrote 




Hi Brian,



On Tuesday, 6 June, 2017 21:48, "Brian Knight" m...@knight-networks.com 
said:



 Because we had different sources of truth which were written in-house, we 
wound up

 rolling our own template engine in Python. It took about 3 weeks to write 
the

 engine and adapt existing templates. Given a circuit ID, it generates the 
full

 config for copy and paste into a terminal session. It also hooks into a

 configuration parser tool, written in-house, that tracks configured 
interfaces, so

 it is easy to see whether the template would overwrite an existing 
interface.



Interesting. I'm going through much the same process at the moment, due to 
similar requirements - multiple sources of truth, validation that there's no 
clash with existing configs, but also with a requirement for network-wide 
atomic operations. The latter has been a strong driver for a custom tool - it's 
now grabbing an exclusive lock on all the devices, making all the checks, 
pushing all the config, commit check everywhere, commit everywhere, and only 
once all the commits succeed, release the locks. If any of those steps fail 
anywhere, we get to roll back everywhere. (Obviously with appropriate timeouts 
/ back-offs / deadlock prevention, and specific to platforms with sane config 
management - no vanilla IOS).





Did you find anything to give you a leg-up on config parsing, or did you have 
to do that completely from scratch? At the moment, I'm working with PyEZ (I 
know, vendor lock-in, but we're firmly a Juniper shop, and going in eyes-open 
to the lock-in) to build a limited model of just the parts of the config I'm 
interested in validating, and it seems to be working.





The import process to the database runs directly on our rancid server, reading 
the downloaded configs out of the appropriate directory within rancid. Most of 
our gear is Cisco, so the ciscoconfparse module for Python helps a lot with 
organizing and querying the config.  From there, the config is parsed for key 
items like interface name, description, configured bandwidth, etc., and that 
info is then added or updated as necessary in the database.



Because it's dependent on rancid, there is some lag time between when a change 
is made and when the database gets updated, so we still strongly encourage 
running the pre-config checks for new circuits.  But with PyEZ, it looks like 
you easily could, after grabbing that lock, validate the existing config before 
pushing down new config.  Lots of possibilities there.  I'm envious that you 
have a vendor-written Python module as a choice!





 If I had a free hand and unlimited budget, I would find a single app that

 functions as a source of truth for all circuits and products, which 
includes a

 templating engine that hooks in easily.



Plus the business buy-in and the resource to go back and standardise all the 
existing configs, so the application can fully parse and understand the network 
before it starts. That, and a pony :)





Or, at least, rebuild the existing configs based on the new source of truth, so 
that subsequent config parsing conforms to a single standard.



Regards,

Tim.









Cheers,



-Brian

RE: Merit RADB support

[Eric Krichbaum]

That's an inherent problem with the IRR system (and I am still a big
proponent).  There is every operational benefit from entering an object. The
object augments policy.  But, what is the benefit of removing an object?  It
doesn't operationally benefit (size of prefix lists, etc. aside) anything.
I would prefer that people who proxy register, also proxy delete when
services are terminated. If wishes were horses

Eric


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Chuck Anderson
Sent: Wednesday, June 07, 2017 11:22 AM
To: nanog@nanog.org
Subject: Re: Merit RADB support

On Wed, Jun 07, 2017 at 12:08:50PM -0400, Chuck Anderson wrote:
> On Wed, Jun 07, 2017 at 10:41:16AM -0500, Kaiser, Erich wrote:
> > Anyone gonna email me back from RADB support?
> 
> In my experience, no.

Apologies to Merit RADB, it was BGPmon that never responds.  Merit RADB
actually does respond--my frustration is more about the difficulty in
getting them to delete stale objects that others registered, although I was
finally able to get my objects cleaned up.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Spectrum TV authentication failures

[Jay R. Ashworth]

- Original Message -
> From: "jra" 

> NANOG is probably not the optimal venue for looking into auth failures on
> the IPTV service which Spectrum/Charter/TWC/BH's TV app for Android uses
> (which are legion), even though it probably uses RADIUS to get the work
> done.

Thanks to a couple people who provided pointers; I'll summarize if anything
useful comes of it...

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

RE: Merit RADB support

[Erik Sundberg]

For RADB, I was able to get them to delete a stale object 2 weeks ago. Only had 
to copy them on an email to the original source and wait 24 hours. I wish it 
was less because we are the netblock owner of the stale route object in 
question.


Erik Sundberg
Sr. Network Engineering
Network Engineering Department
p: 773.661.5532
c: 708.710.7419
e: esundb...@nitelusa.com
Main: 888.450.2100
NOC 24/7: 866.892.0915
350 North Orleans Street, Suite 1300N Chicago, IL 60654
www.nitelusa.com

Managed Telecom Services
MPLS | Ethernet | Private Line | Internet | Voice | Security


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Chuck Anderson
Sent: Wednesday, June 7, 2017 11:22 AM
To: nanog@nanog.org
Subject: Re: Merit RADB support

On Wed, Jun 07, 2017 at 12:08:50PM -0400, Chuck Anderson wrote:
> On Wed, Jun 07, 2017 at 10:41:16AM -0500, Kaiser, Erich wrote:
> > Anyone gonna email me back from RADB support?
>
> In my experience, no.

Apologies to Merit RADB, it was BGPmon that never responds.  Merit RADB 
actually does respond--my frustration is more about the difficulty in getting 
them to delete stale objects that others registered, although I was finally 
able to get my objects cleaned up.



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: Merit RADB support

[Chuck Anderson]

On Wed, Jun 07, 2017 at 12:08:50PM -0400, Chuck Anderson wrote:
> On Wed, Jun 07, 2017 at 10:41:16AM -0500, Kaiser, Erich wrote:
> > Anyone gonna email me back from RADB support?
> 
> In my experience, no.

Apologies to Merit RADB, it was BGPmon that never responds.  Merit
RADB actually does respond--my frustration is more about the
difficulty in getting them to delete stale objects that others
registered, although I was finally able to get my objects cleaned up.

Re: [SPF:Probably_Forged] Merit RADB support

[Chuck Anderson]

On Wed, Jun 07, 2017 at 10:41:16AM -0500, Kaiser, Erich wrote:
> Anyone gonna email me back from RADB support?

In my experience, no.

Merit RADB support

[Kaiser, Erich]

Anyone gonna email me back from RADB support?


Erich Kaiser
The Fusion Network
er...@gotfusion.net
Office: 630-621-4804
Cell: 630-777-9291

Re: IPv4 Hijacking For Idiots

[Scott Christopher]

Mark Andrews wrote: 

> but we do have the tech to do this.

I wholeheartedly agree.

> All it takes is a couple of transit providers to no longer accept 
> word-of-mouth and
> the world will transition overnight.

This is the hard part. 

It seems trivial - being probably only a handful of transit providers -
but then again, these providers have massive infrastructure spread
globally, often ancient legacy systems that still work, and management
has a legal responsibility in most places to maximize the profits of
their shareholders.

Look at the rollout of EMV in the U.S.: the world "has done had that
tech to do that" for decades (in Europe) but it only arrived in the U.S.
two years ago. And the U.S. doesn't do the (more secure) chip-and-pin
like the rest of the world (that costs too much money according to the
banks) but rather chip-and-signature. 

Whereas U.S. banks are (sometimes) liable for fraud on their systems,
transit providers don't have any liability for anything in the U.S. And
they are actively fighting for their right to transit some packets
faster than others - for an additional fee, of course!

I think the solution is legislation + regulations.

-- 
Regards,
  S.C.

Re: AT Broken Uverse IPv6 routing.

[Peter Mayhew]

Brandon,

I have heard some brief mentions on the web about AT converting some 
customers from 6rd to native IPv6 that has caused some problems, but I have not 
heard from enough people to confirm with great certainty. If you look at the RG 
stats page does it still mention 6rd? Out of curiosity, which market are you in 
and which gateways are you seeing this change?

Peter

- Original Message -
From: "Brandon Jackson via NANOG" 
To: nanog@nanog.org
Sent: Tuesday, June 6, 2017 6:32:49 PM
Subject: AT Broken Uverse IPv6 routing.

Sorry for the noise but normal support channels are not understanding IPv6
is broken, they just see IPv4 works.

Can anyone contact me or maybe provide a contact or pass this along to
someone in ATT who can deal with broken IPv6 routing for Uverse Res/Small
Biz IPv6 blocks that are being assigned.

For Example one block that was delegated via DHCP-DP is
2600:1700:8250:8390::/60 tracing to it from anywhere outside of AT gets a
"Destination net unreachable".

Note this seems to have going on since atleast the 31st but likely longer,
that's just when the gateway was updated to DHCP-PD from 6rd. 3 Examples of
traces below.

Note even 2001:506:7825:839::1 seems to issues with connectivity but it
might not matter as much as that just the "WAN" of the gateway.

>From an HE.net connection
 2  ge5-4.core1.ash1.he.net (2001:470:0:90::1)  25.200 ms  24.878 ms
 24.650 ms
 3  100ge3-1.core1.nyc4.he.net (2001:470:0:299::2)  33.407 ms  25.643 ms
 25.245 ms
 4  as7018-att.10gigabitethernet2-3.core1.nyc4.he.net (2001:470:0:1dd::2)
 29.880 ms !N  32.288 ms !N  31.917 ms !N

>From Cogent Looking Glass in ATL

traceroute to 2600:1700:8250:8390::1 (2600:1700:8250:8390::1), 30 hops max,
80 byte packets
 1  2001:550:1:310::1 (2001:550:1:310::1)  0.989 ms  0.992 ms
 2  te0-18-0-2.ccr42.atl01.atlas.cogentco.com (2001:550:0:1000::9a36:2fc5)
 0.983 ms  0.990 ms
 3  be2848.ccr41.atl04.atlas.cogentco.com (2001:550:0:1000::9a36:676)
 2.018 ms be2790.ccr22.atl02.atlas.cogentco.com
(2001:550:0:1000::9a36:1ba6)  1.191 ms
 4  2001:1890:1fff:501:192:205:36:237 (2001:1890:1fff:501:192:205:36:237)
 8.640 ms !N 2001:550:3::166 (2001:550:3::166)  8.270 ms !N


>From Sprint Looking Glass in ATL

traceroute6 to 2600:1700:8250:8390::1 (2600:1700:8250:8390::1) from
2600:0:1:1239:144:228:243:98, 64 hops max, 12 byte packets
 1  sl-mst50-atl-ae10.0.v6.sprintlink.net (2600:0:2:1239:144:232:14:86)
 0.635 ms  0.551 ms  0.457 ms
 2  2600:0:3:1239:144:232:0:6a (2600:0:3:1239:144:232:0:6a)  6.672 ms !N
 7.277 ms !N  7.984 ms !N

Re: Proxying NetFlow traffic correctly

[Mike Sabbota]

Check out samplicator.

https://github.com/sleinen/samplicator

--Mike

On Tue, Jun 6, 2017 at 2:43 PM, Sami via NANOG  wrote:

> Hello,
> I have been searching for a solution that collects/duplicates NetFlow
> traffic properly for a while but i couldn't find any.
> Do you know any good unix alternative to ntopng, flowd, flow-tools?
>
> nprobe of netflow seems to be the closest one to fit my needs but i want
> to see if there are any other solution.
>
> My goal is to centralize NetFlow traffic into a single machine and then
> proxy some flows to other destinations for further analysis
>
> Best Regards,
> Sami

Re: Proxying NetFlow traffic correctly

[Joe Loiacono]

You may want to check out the SiLK netflow capture and analysis tool 
suite. Look in particular at it's SiLK Administrators Tools section which 
provides extensive flexibility for manipulating netflow exports. The 
analysis tools are quite good too.

http://tools.netsa.cert.org/silk/silk-reference-guide.pdf

Joe

"NANOG"  wrote on 06/06/2017 05:43:46 PM:

> From: Sami via NANOG 
> To: "nanog@nanog.org" 
> Date: 06/06/2017 07:33 PM
> Subject: Proxying NetFlow traffic correctly
> Sent by: "NANOG" 
> 
> Hello,
> I have been searching for a solution that collects/duplicates 
> NetFlow traffic properly for a while but i couldn't find any.
> Do you know any good unix alternative to ntopng, flowd, flow-tools?
> 
> nprobe of netflow seems to be the closest one to fit my needs but i 
> want to see if there are any other solution.
> 
> My goal is to centralize NetFlow traffic into a single machine and 
> then proxy some flows to other destinations for further analysis
> 
> Best Regards,
> Sami

Re: Templating/automating configuration

[t...@pelican.org]

Hi Brian,

On Tuesday, 6 June, 2017 21:48, "Brian Knight"  said:

> Because we had different sources of truth which were written in-house, we 
> wound up
> rolling our own template engine in Python. It took about 3 weeks to write the
> engine and adapt existing templates.  Given a circuit ID, it generates the 
> full
> config for copy and paste into a terminal session.  It also hooks into a
> configuration parser tool, written in-house, that tracks configured 
> interfaces, so
> it is easy to see whether the template would overwrite an existing interface.

Interesting.  I'm going through much the same process at the moment, due to 
similar requirements - multiple sources of truth, validation that there's no 
clash with existing configs, but also with a requirement for network-wide 
atomic operations.  The latter has been a strong driver for a custom tool - 
it's now grabbing an exclusive lock on all the devices, making all the checks, 
pushing all the config, commit check everywhere, commit everywhere, and only 
once all the commits succeed, release the locks.  If any of those steps fail 
anywhere, we get to roll back everywhere.  (Obviously with appropriate timeouts 
/ back-offs / deadlock prevention, and specific to platforms with sane config 
management - no vanilla IOS).

Did you find anything to give you a leg-up on config parsing, or did you have 
to do that completely from scratch?  At the moment, I'm working with PyEZ (I 
know, vendor lock-in, but we're firmly a Juniper shop, and going in eyes-open 
to the lock-in) to build a limited model of just the parts of the config I'm 
interested in validating, and it seems to be working.

> If I had a free hand and unlimited budget, I would find a single app that
> functions as a source of truth for all circuits and products, which includes a
> templating engine that hooks in easily.

Plus the business buy-in and the resource to go back and standardise all the 
existing configs, so the application can fully parse and understand the network 
before it starts.  That, and a pony :)

Regards,
Tim.

Telxius AS12956

[Marco Paesani]

Hi,
I need a peering contact for Telxius, can you help me ?
Thanks !
kind regards,

Marco Paesani


Skype: mpaesani
Mobile: +39 348 6019349
Success depends on the right choice !
Email: ma...@paesani.it

Re: Templating/automating configuration

[James Bensley]

On 7 June 2017 at 00:43, Vincent Bernat  wrote:
>  ❦  6 juin 2017 14:30 +0100, Oliver Elliott  :
>
>> I echo Ansible. I'm using it with NAPALM and jinja2 templates to push and
>> verify config on switches.
>
> Why not using the builtin ability of ansible for most vendors? (genuine
> question)
>
>  http://docs.ansible.com/ansible/list_of_network_modules.html

One reason, which is our reason for using NAPALM with Ansible, is that
the built in Ansible modules often just edit certain lines of config
in the target device. For example, the Cisco IOS module within Ansible
scans the device config for say the line starting with "Interface
Etherernet 1/1" and then I tell it to ensure the lines " ip vrf
customer A" and " ip address x.x.x.x n.n.n.n" are under the search
line. It's OK but its text matching and not fool proof. It also
doesn't help me to guarantee the state of our tin (I might push an
update to one interface on a device and simultaneously someone else
might pushes an update to a different interface, our respective views
of the device config might not include each other’s updates).

We use the NAPALM module although it needs to be a bit more than just
NAPALM, its not a panacea. We generate a full device config (even for
a one line interface update) and push that into atomic storage (git),
when then pass that file from git to NAPALM. NAPALM will copy the file
to the device and do a full config replace for us, and we can get a
diff from before and after that process and report that back and
ensure that exactly what we wanted to change has been changed only.
All changes come through git which act’s like a queue meaning that if
two people make simultaneous updates to different interfaces there’ll
be a git commit/push error. [1]

Cheers,
James.

[1] That’s the plan at least, the reality though is that vendor bugs
are plentiful.

Re: IPv4 Hijacking For Idiots

[Mark Andrews]

In message <1496816542.3628250.1001312328.70df4...@webmail.messagingengine.com>
, Scott Christopher writes:
> Mark Andrews wrote: 
> 
> > but we do have the tech to do this.
> 
> I wholeheartedly agree.
> 
> > All it takes is a couple of transit providers to no longer accept word-of-m
> outh and
> > the world will transition overnight.
> 
> This is the hard part. 
> 
> It seems trivial - being probably only a handful of transit providers -
> but then again, these providers have massive infrastructure spread
> globally, often ancient legacy systems that still work, and management
> has a legal responsibility in most places to maximize the profits of
> their shareholders.
> 
> Look at the rollout of EMV in the U.S.: the world "has done had that
> tech to do that" for decades (in Europe) but it only arrived in the U.S.
> two years ago. And the U.S. doesn't do the (more secure) chip-and-pin
> like the rest of the world (that costs too much money according to the
> banks) but rather chip-and-signature. 
> 
> Whereas U.S. banks are (sometimes) liable for fraud on their systems,
> transit providers don't have any liability for anything in the U.S. And
> they are actively fighting for their right to transit some packets
> faster than others - for an additional fee, of course!
 
Actually they do have liability. It just needs someone to sue them
for them to wake up.  The injured party isn't a customer of the
transit provider so there isn't any weasle worded contract to sace
the transit provider.

> I think the solution is legislation + regulations.
> 
> -- 
> Regards,
>   S.C.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org