Re: BCP38 tester?

[Jimmy Hess]

On 3/31/13, Karl Auer  wrote:
> On Mon, 2013-04-01 at 15:07 +1100, Mark Andrews wrote:
>> In message <1364787851.2136.7.camel@karl>, Karl Auer writes:
>> > A side effect of NAT is to clamp the source address range

>> It depends on how the nat is configured.
> OK - how does one configure NAT so that the source addresses of outbound
> packets are NOT clamped to a configured range on the outside of the NAT
> device? Given this general scenario, of course:

He said it depends on how NAT is configured;  but really, before it
depends on that -- it first depends on what kind of device is used,
and what kind of NAT is being implemented.

In some implementations, only certain ranges of source IP addresses
are subject to translation.They might be NAT'ing based on network,
interface, or access-list.

>Inside  Outside
>Nasty spoofing scum > NAT ---> helpless victims
>   Outbound --->


It occurs that if the CPE are /truly/  clamping the Source address
space,  then essence,
BCP38  is essentially happening at the CPE.

If your packet source address is clamped, then, by definition a host
can't spoof a packet, right;  so maybe that's not a host that needs to
be tested further  (the upstream provider might still have no BCP38,
it's just not exposed to that particular host).

Unless, of course, there are protocols your NAT device passes
unaltered such as possibly ICMP,  or  ICMPv6,   in case   NAT only
applies to IPv4,  a host behind the NAT might still be able to spoof
IPv6  source addresses.

--
-JH

Re: BCP38 tester?

[Karl Auer]

On Mon, 2013-04-01 at 15:07 +1100, Mark Andrews wrote:
> In message <1364787851.2136.7.camel@karl>, Karl Auer writes:
> > A side effect of NAT is to clamp the source address range
> > of outbound packets to the configured NAT outside address
> > range.
> It depends on how the nat is configured.

OK - how does one configure NAT so that the source addresses of outbound
packets are NOT clamped to a configured range on the outside of the NAT
device? Given this general scenario, of course:

   Inside  Outside
   Nasty spoofing scum > NAT ---> helpless victims
  Outbound --->

Honest question - just 'because I don't see it doesn't mean it isn't
possible :-) My NAT configs have generally been pretty plain vanilla.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

Re: BCP38 tester?

[Mark Andrews]

In message <1364787851.2136.7.camel@karl>, Karl Auer writes:
> On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote:
> > This thought crossed my mind earlier today, when I asked Jeff if IP-forged
> > packets would make it through a NAT, outbound.  He said no (I think), but 
> > I'm not entirely sure that's right.
> 
> Welll - the packets might make it out, and be transmitted into the
> Internet, but they would have a legitimate source address, namely an
> outside address of the NAT router. A side effect of NAT is to clamp the
> source address range of outbound packets to the configured NAT outside
> address range.
> 
> Regards, K.

It depends on how the nat is configured.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: BCP38 tester?

[Karl Auer]

On Sun, 2013-03-31 at 22:32 -0400, Jay Ashworth wrote:
> This thought crossed my mind earlier today, when I asked Jeff if IP-forged
> packets would make it through a NAT, outbound.  He said no (I think), but 
> I'm not entirely sure that's right.

Welll - the packets might make it out, and be transmitted into the
Internet, but they would have a legitimate source address, namely an
outside address of the NAT router. A side effect of NAT is to clamp the
source address range of outbound packets to the configured NAT outside
address range.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

Re: Open Resolver Problems

[Valdis . Kletnieks]

On Sun, 31 Mar 2013 16:09:35 -0500, Jimmy Hess said:
> On 3/29/13, Scott Noel-Hemming  wrote:
> >> Some of us have both publicly-facing authoritative DNS, and inward
> >> facing recursive servers that may be open resolvers but can't be
> >> found via NS entries (so the IP addresses of those aren't exactly
> >> publicly available info).
> > Sounds like your making the faulty assumption that an attacker would use
> > normal means to find your servers.
>
> A distributed scan of the entire IPv4 

Stop right there.

Anybody who is looking at this as an IPv4 issue is woefully misinformed
about the nature of the problem.




pgpZjTKuPJhri.pgp
Description: PGP signature

Re: BCP38 tester?

[Jay Ashworth]

- Original Message -
> From: "Jason Lixfeld" 

> I believe that most everyone has a CPE of some sort, whether their
> service is resi or commercial. So, what about shifting the focus to
> the CPE manufacturers? They bend to technology and/or market pressures
> by bringing things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE,
> RFC1483, etc. to their respective products in to satisfy technology
> limitations or security concerns or whatever. Why can't they help the
> cause by implementing some sort of RFC'ified BCP38 thing?

This thought crossed my mind earlier today, when I asked Jeff if IP-forged
packets would make it through a NAT, outbound.  He said no (I think), but 
I'm not entirely sure that's right.

While that would be egress filtering, from the POV of the home-LAN, it
would still help in the trojan-horse-bot situation, as long as it couldn't
be opened up via something like PPTP, and would thus still be useful,
to some extent, sure.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: BCP38 tester?

[Jay Ashworth]

- Original Message -
> From: "Alain Hebert" 

> An easy target would be anti-virus/trojan/security software
> providers that could add a BCP38 check to their software =D

Yes, but penetration is a problem, which is why I was thinking about
people like YouTube, Ookla, and the like.

Any Flash app that lots of people run frequently.  Assuming those apps
could generate the packets, which, on reflection, I would bet they can't.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: Tier 2 ingress filtering

[William Herrin]

Hi Alejandro,

Also inline.

On Sat, Mar 30, 2013 at 10:17 PM, Alejandro Acosta
 wrote:
> Hi William,
>   Thanks for your response, my comments below:
>
> On 3/30/13, William Herrin  wrote:
> > On Fri, Mar 29, 2013 at 11:21 PM, Alejandro Acosta
> >  wrote:
> >> On 3/29/13, Patrick  wrote:
> >>> On 2013-03-29 14:49, William Herrin wrote:
>  I've long thought router vendors should introduce a configuration
>  option to specify the IP address from which ICMP errors are emitted
>  rather than taking the interface address from which the packet causing
>  the error was received.
> >>>
> >>> Concur. An 'ip(v6)? icmp source-interface loop0' sure beats running 'ip
> >>> unnumbered loop0' everywhere. ;)
> >>
> >> Why do you think it will be better?, can you explain?
> >
> > Hi Alejandro,
> >
> > Consider the alternatives:
> >
> > 1. Provide a router configuration option (per router and/or per
> > interface) to emit ICMP error messages from a specified IP address
> > rather than the interface address.
>
> I imagine that and it sounds terrific. I guess at least this option
> should come disabled by default.
>
> > 2. At every border, kick packets without an Internet-legitimate source
> > address up to the slow path for network address translation to a
> > source address which is valid.
>
> IMHO this can be achieved with the current behaviour.

If you don't mind the router crashing. There's too much trash traffic
with bad source addresses, even when no one is under attack. You kick
it up to the main CPU, you overwhelm the router.


> > 3. Design your network so that any router with at least one network
> > interface whose IP address is not valid on the Internet has exactly
> > the same MTU on every interface, and at least an MTU of 1500 on all of
> > them, guaranteeing that the router will never emit a
> > fragmentation-needed message. And do this consistently. Every time.
>
> If you have pmtud enabled you won't need this every time

Clients effectively always enable path MTU discovery.  If the ICMP
error message your router generates when it discovers the MTU problem
comes from an IP address that can't leave your system without being
filtered then path MTU discovery fails absolutely. That path is a
black hole that mysteriously swallows TCP connections.

If you can't prevent mis-addressed ICMP error messages from leaving
your system then you must prevent the conditions under which path MTU
discovery would cause an ICMP error message to be generated.
Practically speaking, that means you guarantee an MTU of at least 1500
bytes on every link and no endpoint MTU over 1500 bytes.


> > 4. Redesign TCP so it doesn't rely on ICMP destination unreachable
> > messages to determine path MTU and get your new design deployed into
> > every piece of software on the Internet.
>
> You will have the same problem using only one output interface for
> ICMP error/messages. Of course based in your comments you mean you
> will need to troubleshoot this interface only once.

With #4, path mtu discovery no longer relies on ICMP error messages.
The endpoint client would have to reduce the MSS on retransmission and
use the pattern of lost packets to acknowledgements to find path MTU
on paths with an ICMP black hole.

For the sake of robustness, this is something we probably should think
seriously about adding to the TCP protocol. However, that's a long
plan, two decades at least. It isn't something that could deliver a
complete mitigation in the next release of the software, the way
option 1 does.


> > 5. Accept that TCP will break unexpectedly due to lost
> > fragmentation-needed messages, presenting as a particularly nasty and
> > intermittent failure that's hard to track and harder to fix.
>
> Same answer as in 3.

See me response to #3.

Regards,
Bill Herrin



--
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: BCP38 tester?

[Alain Hebert]

  On 03/31/13 21:50, Jason Lixfeld wrote:
> On 2013-03-31, at 9:43 PM, Peter Baldridge  wrote:
>
>> I can assume that If you are spoofing packets, resetting passwords on cpe 
>> and replacing the box would be trivial.  So it's questionable how useful 
>> this is.  It seems like it just adds cost to for customers that can't spoof 
>> a packet to save their lives.
> Maybe it's useful for the people who have no idea that their computers are 
> infected by bots that spoof packets.
>
>> On Mar 31, 2013 6:37 PM, "Jason Lixfeld"  wrote:
>>
>> On 2013-03-31, at 10:48 AM, Jay Ashworth  wrote:
>>
>>> Is there a program which users can run on an end-site workstation which
>>> would test whether they are being some link which is doing BCP38, or some
>>> related type of source-address ingress filtering?
>>>
>>> I'm hoping for something that could be downloaded by users and run, and
>>> try to forge a few packets to somewhere useful, which could be logged
>>> somehow in conjunction with some unforged packets containing a traceroute,
>>> so we could build up a database of leaky networks.
>>>
>>> On a related topic, while I know GRC Research's Steve Gibson is a bit of
>>> a polarizing personality, he does have a fairly sizable consumer audience,
>>> and might be a great distribution venue for such a thing.
>>>
>>> Or, perhaps, is there someone on here from Ookla?
>>>
>>> Patrick?  Could Akamai be persuaded to take an interest in this as a
>>> research project?
>>
>> From my perspective, 99% of end-users probably don't understand (or care) 
>> that their provider might be responsible for initiating or precipitating a 
>> DDoS attacks, period.  Most network operators are probably either too 
>> inexperienced to understand or too lazy to care.
>>
>> I believe that most everyone has a CPE of some sort, whether their service 
>> is resi or commercial.  So, what about shifting the focus to the CPE 
>> manufacturers?  They bend to technology and/or market pressures by bringing 
>> things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to 
>> their respective products in to satisfy technology limitations or security 
>> concerns or whatever.  Why can't they help the cause by implementing some 
>> sort of RFC'ified BCP38 thing?
>>

An easy target would be anti-virus/trojan/security software
providers that could add a BCP38 check to their software =D

-
Alain Hebertaheb...@pubnix.net   
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

Re: BCP38 tester?

[Jon Lewis]

Someone privately emailed me asking about the problems I had.  When I 
looked at it some more, I found the autoconf error was just very 
misleading, and my build environment was incomplete.  With all the right 
tools installed, it built just fine on the Ubuntu 12.04 64-bit machine I 
was playing on.


On Sun, 31 Mar 2013, Jon Lewis wrote:


They should updated their autoconf.  It fails on modern 64-bit Linux.

On Sun, 31 Mar 2013, Paul Ferguson wrote:


You mean like this? :-)

http://spoofer.csail.mit.edu/

- ferg


On Sun, Mar 31, 2013 at 7:48 AM, Jay Ashworth  wrote:


Is there a program which users can run on an end-site workstation which
would test whether they are being some link which is doing BCP38, or some
related type of source-address ingress filtering?

I'm hoping for something that could be downloaded by users and run, and
try to forge a few packets to somewhere useful, which could be logged
somehow in conjunction with some unforged packets containing a traceroute,
so we could build up a database of leaky networks.

On a related topic, while I know GRC Research's Steve Gibson is a bit of
a polarizing personality, he does have a fairly sizable consumer audience,
and might be a great distribution venue for such a thing.

Or, perhaps, is there someone on here from Ookla?

Patrick?  Could Akamai be persuaded to take an interest in this as a
research project?

Cheers,
-- jra
--
Jay R. Ashworth  Baylink 
j...@baylink.com
Designer The Things I Think   RFC 
2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover 
DII
St Petersburg FL USA   #natog  +1 727 647 
1274






--
"Fergie", a.k.a. Paul Ferguson
fergdawgster(at)gmail.com



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



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

Re: BCP38 tester?

[Jason Lixfeld]

On 2013-03-31, at 9:43 PM, Peter Baldridge  wrote:

> I can assume that If you are spoofing packets, resetting passwords on cpe and 
> replacing the box would be trivial.  So it's questionable how useful this is. 
>  It seems like it just adds cost to for customers that can't spoof a packet 
> to save their lives.

Maybe it's useful for the people who have no idea that their computers are 
infected by bots that spoof packets.

> On Mar 31, 2013 6:37 PM, "Jason Lixfeld"  wrote:
> 
> On 2013-03-31, at 10:48 AM, Jay Ashworth  wrote:
> 
> > Is there a program which users can run on an end-site workstation which
> > would test whether they are being some link which is doing BCP38, or some
> > related type of source-address ingress filtering?
> >
> > I'm hoping for something that could be downloaded by users and run, and
> > try to forge a few packets to somewhere useful, which could be logged
> > somehow in conjunction with some unforged packets containing a traceroute,
> > so we could build up a database of leaky networks.
> >
> > On a related topic, while I know GRC Research's Steve Gibson is a bit of
> > a polarizing personality, he does have a fairly sizable consumer audience,
> > and might be a great distribution venue for such a thing.
> >
> > Or, perhaps, is there someone on here from Ookla?
> >
> > Patrick?  Could Akamai be persuaded to take an interest in this as a
> > research project?
> 
> 
> From my perspective, 99% of end-users probably don't understand (or care) 
> that their provider might be responsible for initiating or precipitating a 
> DDoS attacks, period.  Most network operators are probably either too 
> inexperienced to understand or too lazy to care.
> 
> I believe that most everyone has a CPE of some sort, whether their service is 
> resi or commercial.  So, what about shifting the focus to the CPE 
> manufacturers?  They bend to technology and/or market pressures by bringing 
> things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to 
> their respective products in to satisfy technology limitations or security 
> concerns or whatever.  Why can't they help the cause by implementing some 
> sort of RFC'ified BCP38 thing?

Re: Open Resolver Problems

[Jared Mauch]

On Mar 31, 2013, at 5:09 PM, Jimmy Hess  wrote:

> On 3/29/13, Scott Noel-Hemming  wrote:
>>> Some of us have both publicly-facing authoritative DNS, and inward
>>> facing recursive servers that may be open resolvers but can't be
>>> found via NS entries (so the IP addresses of those aren't exactly
>>> publicly available info).
>> Sounds like your making the faulty assumption that an attacker would use
>> normal means to find your servers.
> 
> A distributed scan of the entire IPv4 space for all internet IPs
> running open DNS servers is fairly doable;  actually a long term scan
> taking 100 to 200 days of continuous DNS scanning  is completely
> trivial.

I updated the openresolverproject.org data in less than 8 hours.

The system would scan 1.0.0.0 , 1.0.0.1 … in sequence.

Next time it runs, it's going to use a slightly different method which may 
expose a few more servers.

The 2013-Mar-31 data showed:

2,471,484  servers returned refused. (369k change downward)
20,675,738 with correct answer in packet.

If I extrapolate 369k/week closing, everything will be closed in about a year.

(Compared to 2.1 mil refused the week before; compared to 21.4 Million with 
correct answer in packet the week before).

I know many people are working on their respective hosts and/or network to 
close things down.

Many thanks to everyone that is treating this as a critical issue to close 
these hosts.

- jared

Re: BCP38 tester?

[Jason Lixfeld]

On 2013-03-31, at 10:48 AM, Jay Ashworth  wrote:

> Is there a program which users can run on an end-site workstation which
> would test whether they are being some link which is doing BCP38, or some
> related type of source-address ingress filtering?
> 
> I'm hoping for something that could be downloaded by users and run, and
> try to forge a few packets to somewhere useful, which could be logged 
> somehow in conjunction with some unforged packets containing a traceroute, 
> so we could build up a database of leaky networks.
> 
> On a related topic, while I know GRC Research's Steve Gibson is a bit of
> a polarizing personality, he does have a fairly sizable consumer audience,
> and might be a great distribution venue for such a thing.
> 
> Or, perhaps, is there someone on here from Ookla?
> 
> Patrick?  Could Akamai be persuaded to take an interest in this as a 
> research project?


From my perspective, 99% of end-users probably don't understand (or care) that 
their provider might be responsible for initiating or precipitating a DDoS 
attacks, period.  Most network operators are probably either too inexperienced 
to understand or too lazy to care.

I believe that most everyone has a CPE of some sort, whether their service is 
resi or commercial.  So, what about shifting the focus to the CPE 
manufacturers?  They bend to technology and/or market pressures by bringing 
things like NAT, Firewalls, DLNA, UPnP, IPv6 (heh), PPPoE, RFC1483, etc. to 
their respective products in to satisfy technology limitations or security 
concerns or whatever.  Why can't they help the cause by implementing some sort 
of RFC'ified BCP38 thing?

Dropping connectivity for Cyberbunker?

[Joseph Chin]

This article talks about convincing direct peers and transit providers to
stop Net connectivity to the culprit
http://www.darkreading.com/blog/240151931/who-supplies-cyberbunker.html

 

Would it not be easier if a majority of the ISPs simply filter BGP prefixes
containing the aforementioned ASes in the paths? Maybe many of you are
already quietly doing it? This probably won't stop the baddies from spoofing
source addresses for attacks, but it will make Cyberbunker economically
unviable as no one will be able to reach assets hosted on their IP
addresses. They have proven beyond a reasonable doubt that they have no
intention to behave as civilized Netizens. So why should the rest of us
continue to play nice? Does anyone see a problem with this action?

 

Re: Open Resolver Problems

[Jimmy Hess]

On 3/29/13, Scott Noel-Hemming  wrote:
>> Some of us have both publicly-facing authoritative DNS, and inward
>> facing recursive servers that may be open resolvers but can't be
>> found via NS entries (so the IP addresses of those aren't exactly
>> publicly available info).
> Sounds like your making the faulty assumption that an attacker would use
> normal means to find your servers.

A distributed scan of the entire IPv4 space for all internet IPs
running open DNS servers is fairly doable;  actually a long term scan
taking 100 to 200 days of continuous DNS scanning  is completely
trivial.


The fact a recursive DNS server exists at a certain IP address can
also be exposed to the operators of authoritative (or root) DNS
servers, through the queries that the recursive servers make.

For example:  an internet advertiser can place syndicated ads on
certain websites, containing images referring to a server on their
domain (that requires resolving their domain),  and then mine data
from the IP addresses that are contacting their authoritative DNS
servers in order to make queries.



For some domains, the authoritative DNS servers might even want to
ping the recursor, and use the result to decide what set of answers to
send for future queries,  in order to reply with choices that are
anticipated to minimize latency.

-- 
-JH

Re: BCP38 tester?

[Jon Lewis]

They should updated their autoconf.  It fails on modern 64-bit Linux.

On Sun, 31 Mar 2013, Paul Ferguson wrote:


You mean like this? :-)

http://spoofer.csail.mit.edu/

- ferg


On Sun, Mar 31, 2013 at 7:48 AM, Jay Ashworth  wrote:


Is there a program which users can run on an end-site workstation which
would test whether they are being some link which is doing BCP38, or some
related type of source-address ingress filtering?

I'm hoping for something that could be downloaded by users and run, and
try to forge a few packets to somewhere useful, which could be logged
somehow in conjunction with some unforged packets containing a traceroute,
so we could build up a database of leaky networks.

On a related topic, while I know GRC Research's Steve Gibson is a bit of
a polarizing personality, he does have a fairly sizable consumer audience,
and might be a great distribution venue for such a thing.

Or, perhaps, is there someone on here from Ookla?

Patrick?  Could Akamai be persuaded to take an interest in this as a
research project?

Cheers,
-- jra
--
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274





--
"Fergie", a.k.a. Paul Ferguson
fergdawgster(at)gmail.com



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

Re: BCP38 tester?

[Jay Ashworth]

- Original Message -
> From: "Paul Ferguson" 

> You mean like this? :-)
> 
> http://spoofer.csail.mit.edu/

I dunno; does that automatically submit the details to a central site,
and not bother the user with anything more than "Your connection appears
to be protected with BCP38 filtering" or "No, your provider appears not
to be using BCP38 filtering; we'll let them know"?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: BCP38 tester?

[Paul Ferguson]

You mean like this? :-)

http://spoofer.csail.mit.edu/

- ferg


On Sun, Mar 31, 2013 at 7:48 AM, Jay Ashworth  wrote:

> Is there a program which users can run on an end-site workstation which
> would test whether they are being some link which is doing BCP38, or some
> related type of source-address ingress filtering?
>
> I'm hoping for something that could be downloaded by users and run, and
> try to forge a few packets to somewhere useful, which could be logged
> somehow in conjunction with some unforged packets containing a traceroute,
> so we could build up a database of leaky networks.
>
> On a related topic, while I know GRC Research's Steve Gibson is a bit of
> a polarizing personality, he does have a fairly sizable consumer audience,
> and might be a great distribution venue for such a thing.
>
> Or, perhaps, is there someone on here from Ookla?
>
> Patrick?  Could Akamai be persuaded to take an interest in this as a
> research project?
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
> St Petersburg FL USA   #natog  +1 727 647 1274
>



--
"Fergie", a.k.a. Paul Ferguson
 fergdawgster(at)gmail.com

BCP38 tester?

[Jay Ashworth]

Is there a program which users can run on an end-site workstation which
would test whether they are being some link which is doing BCP38, or some
related type of source-address ingress filtering?

I'm hoping for something that could be downloaded by users and run, and
try to forge a few packets to somewhere useful, which could be logged 
somehow in conjunction with some unforged packets containing a traceroute, 
so we could build up a database of leaky networks.

On a related topic, while I know GRC Research's Steve Gibson is a bit of
a polarizing personality, he does have a fairly sizable consumer audience,
and might be a great distribution venue for such a thing.

Or, perhaps, is there someone on here from Ookla?

Patrick?  Could Akamai be persuaded to take an interest in this as a 
research project?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

[Q] Any detailed enterprise WAN QoS design/config for MPLS services, f/various ISPs?

[Stefan]

Been looking for Verizon and AT&T AVPN MPLS, specifically. Pointers highly
appreciated, as the nanog archive does not seem to have searchable items
ref such. Cisco docs have some info, but I am mostly looking for tried and
proven configs with the specifics that Verizon and AT&T offer.

Traditional AT&T (e.g.) means involve the likes of (for main DC):

policy-map 
 description  CoS Profile  % RT (nb1/nb2/nb3)
  class <0>
priority percent 
  class <1>
   set dscp af21
bandwidth 
  class C<2>
   set dscp af31
bandwidth 
policy-map <3>
  class <4>
   set dscp af21
  class <5>
   set dscp af31
  class <6>
priority percent 
policy-map 
  class class-default
shape average 
   service-policy 
...
interface GigabitEthernet2/0/0.x
...
 ip pim sparse-mode
 service-policy output <3>
...
or the likes (can't even tell if I consistently sanitized the info, but you
get the point)

I am interested in main hub/DC + remotes - docs, preferably.

TIA,
***Stefan