Re: Time to add 2002::/16 to bogon filters?
On Mon, 18 Jun 2018 21:08:05 +0000 Job Snijders <job@ntt.net> wrote:
TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
Hi Job, I've been asking people about this recently. I don't particularly like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here. John
This should have been filtered before. Lots of people improperly implemented this so it caused issues. Mack -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of John Kristoff Sent: Monday, June 18, 2018 3:48 PM To: Job Snijders <job@ntt.net> Cc: NANOG [nanog@nanog.org] <nanog@nanog.org> Subject: Re: Time to add 2002::/16 to bogon filters? On Mon, 18 Jun 2018 21:08:05 +0000 Job Snijders <job@ntt.net> wrote:
TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
Hi Job, I've been asking people about this recently. I don't particularly like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here. John E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It they don’t want it all they have to do is withdraw the prefix. It is not up to the rest of us to second guess their decision to keep providing support. If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY. None of the problems required removing it from BGP. There were end sites that had firewalls that blocked 6to4 responses and the odd site that ran a gateway and failed to properly manage it. The rest could have been dealt with by configuring more gateways. If every dual stacked ASN had run their own gateways there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic and dump it onto IPv4 as soon as possible and take the encapsulated traffic for the rest of IPv6 and de-encapsulate it as soon as possible. Mark
On 19 Jun 2018, at 8:56 am, McBride, Mack <C-Mack.McBride@charter.com> wrote:
This should have been filtered before. Lots of people improperly implemented this so it caused issues.
Mack
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of John Kristoff Sent: Monday, June 18, 2018 3:48 PM To: Job Snijders <job@ntt.net> Cc: NANOG [nanog@nanog.org] <nanog@nanog.org> Subject: Re: Time to add 2002::/16 to bogon filters?
On Mon, 18 Jun 2018 21:08:05 +0000 Job Snijders <job@ntt.net> wrote:
TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
Hi Job,
I've been asking people about this recently. I don't particularly like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here.
John E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews <marka@isc.org> wrote:
If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It they don’t want it all they have to do is withdraw the prefix. It is not up to the rest of us to second guess their decision to keep providing support.
That sounds like an interesting attack scenario where a malicious actor can insert themselves in a path, via bgp, announcing 6to4 space
If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY.
None of the problems required removing it from BGP. There were end sites that had firewalls that blocked 6to4 responses and the odd site that ran a gateway and failed to properly manage it. The rest could have been dealt with by configuring more gateways. If every dual stacked ASN had run their own gateways there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic and dump it onto IPv4 as soon as possible and take the encapsulated traffic for the rest of IPv6 and de-encapsulate it as soon as possible.
On 19 Jun 2018, at 8:56 am, McBride, Mack <C-Mack.McBride@charter.com> wrote:
This should have been filtered before. Lots of people improperly implemented this so it caused issues.
Mack
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of John Kristoff Sent: Monday, June 18, 2018 3:48 PM To: Job Snijders <job@ntt.net> Cc: NANOG [nanog@nanog.org] <nanog@nanog.org> Subject: Re: Time to add 2002::/16 to bogon filters?
On Mon, 18 Jun 2018 21:08:05 +0000 Job Snijders <job@ntt.net> wrote:
TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
Hi Job,
I've been asking people about this recently. I don't particularly like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here.
John E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally
Mark privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
If you are using 2002::/16 you know are relying on third parties. Not that it is much different to any other address where you are relying on third parties. If one is going to filter 2002::/16 from BGP then install your own gateway to preserve the functionality.
On 19 Jun 2018, at 10:23 am, Ca By <cb.list6@gmail.com> wrote:
On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews <marka@isc.org> wrote: If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It they don’t want it all they have to do is withdraw the prefix. It is not up to the rest of us to second guess their decision to keep providing support.
That sounds like an interesting attack scenario where a malicious actor can insert themselves in a path, via bgp, announcing 6to4 space
If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY.
None of the problems required removing it from BGP. There were end sites that had firewalls that blocked 6to4 responses and the odd site that ran a gateway and failed to properly manage it. The rest could have been dealt with by configuring more gateways. If every dual stacked ASN had run their own gateways there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic and dump it onto IPv4 as soon as possible and take the encapsulated traffic for the rest of IPv6 and de-encapsulate it as soon as possible.
Mark
On 19 Jun 2018, at 8:56 am, McBride, Mack <C-Mack.McBride@charter.com> wrote:
This should have been filtered before. Lots of people improperly implemented this so it caused issues.
Mack
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of John Kristoff Sent: Monday, June 18, 2018 3:48 PM To: Job Snijders <job@ntt.net> Cc: NANOG [nanog@nanog.org] <nanog@nanog.org> Subject: Re: Time to add 2002::/16 to bogon filters?
On Mon, 18 Jun 2018 21:08:05 +0000 Job Snijders <job@ntt.net> wrote:
TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
Hi Job,
I've been asking people about this recently. I don't particularly like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here.
John E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mon, Jun 18, 2018 at 5:31 PM Mark Andrews <marka@isc.org> wrote:
If you are using 2002::/16 you know are relying on third parties.
I highlly doubt most people using 6to4 know they are using it, let alone the arbitrary nature of its routing. Not that it is much
different to any other address where you are relying on third parties.
If one is going to filter 2002::/16 from BGP then install your own gateway to preserve the functionality.
On 19 Jun 2018, at 10:23 am, Ca By <cb.list6@gmail.com> wrote:
On Mon, Jun 18, 2018 at 4:37 PM Mark Andrews <marka@isc.org> wrote: If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It they don’t want it all they have to do is withdraw the prefix. It is not up to the rest of us to second guess their decision to keep providing support.
That sounds like an interesting attack scenario where a malicious actor can insert themselves in a path, via bgp, announcing 6to4 space
If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY.
None of the problems required removing it from BGP. There were end sites that had firewalls that blocked 6to4 responses and the odd site that ran a gateway and failed to properly manage it. The rest could have been dealt with by configuring more gateways. If every dual stacked ASN had run their own gateways there wouldn’t have been a scaling issue. i.e. take the 2002::/16 traffic and dump it onto IPv4 as soon as possible and take the encapsulated traffic for the rest of IPv6 and de-encapsulate it as soon as possible.
On 19 Jun 2018, at 8:56 am, McBride, Mack <C-Mack.McBride@charter.com> wrote:
This should have been filtered before. Lots of people improperly implemented this so it caused issues.
Mack
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of John Kristoff Sent: Monday, June 18, 2018 3:48 PM To: Job Snijders <job@ntt.net> Cc: NANOG [nanog@nanog.org] <nanog@nanog.org> Subject: Re: Time to add 2002::/16 to bogon filters?
On Mon, 18 Jun 2018 21:08:05 +0000 Job Snijders <job@ntt.net> wrote:
TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
Hi Job,
I've been asking people about this recently. I don't particularly
Mark like having misdirected traffic or badly configured hosts sending junk to those who happen to be announcing addresses from this prefix. I'm planning on adding this to a bogon filter here.
John E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended
solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, cop <https://maps.google.com/?q=ed+that+any+use,+dissemination,+distribution,+cop&entry=gmail&source=g>ying, or storage of this message or any attachment is strictly prohibited.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
20 years from now when the IETF decides to reclaim / repurpose that prefix, y'all are going to have to run around removing it from your filters again... -- Harald
On Jun 18, 2018, at 8:31 PM, Mark Andrews <marka@isc.org> wrote:
If you are using 2002::/16 you know are relying on third parties. Not that it is much different to any other address where you are relying on third parties.
If one is going to filter 2002::/16 from BGP then install your own gateway to preserve the functionality.
It does not appear the functionality is working at present, which I think is the more critical point. Taking a quick sampling of where I see the packets going from two different networks, it doesn’t seem to be going where it’s expected, nor is it working as expected. These appear to be at best routing leaks similar to leaking rfc6761 space that should be under your local control. They could also be seen as a privacy issue by taking packets destined to 2002::/16 somewhere unexpected and off-continent. I would expect even in the cases where it does work, it would be subject to the same challenges faced by people using VPN services (being blocked from your kids favorite streaming services) and much poorer performance than native IPv4. There is also the problem noted by Wes George with 6to4 being used in DNS amplification, which may be interesting.. http://iepg.org/2018-03-18-ietf101/wes.pdf I don’t believe most providers are intending to offer 6to4 as a global service. Even the large providers (eg: Comcast) seem to have disabled it ~4+ years ago. While I know there’s people on the internet that like to hang on to legacy things, this is one that should end. The networks and devices today no longer require this sort of transition technology, and the networks where it’s left won’t want it as it will be used for various bad things(tm). - Jared
This week I began mapping IPv6 SPAM headers "Received:" and "X-Received:" and have discovered over 50% are from: 10.0.0.0 – 10.255.255.255 2002:0a00:: - 2002:aff:ffff:ffff:ffff:ffff:ffff:ffff 172.16.0.0 – 172.31.255.255 2002:ac10:: - 2002:ac10:ffff:ffff:ffff:ffff:ffff:ffff 192.168.0.0 – 192.168.255.255 2002:c0A8:: - 2002:c0A8:ffff:ffff:ffff:ffff:ffff:ffff Can anyone else confirm my findings? Joe Klein "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1) PGP Fingerprint: 295E 2691 F377 C87D 2841 00C1 4174 FEDF 8ECF 0CC8 On Mon, Jun 18, 2018 at 9:18 PM, Jared Mauch <jared@puck.nether.net> wrote:
On Jun 18, 2018, at 8:31 PM, Mark Andrews <marka@isc.org> wrote:
If you are using 2002::/16 you know are relying on third parties. Not that it is much different to any other address where you are relying on third parties.
If one is going to filter 2002::/16 from BGP then install your own gateway to preserve the functionality.
It does not appear the functionality is working at present, which I think is the more critical point. Taking a quick sampling of where I see the packets going from two different networks, it doesn’t seem to be going where it’s expected, nor is it working as expected. These appear to be at best routing leaks similar to leaking rfc6761 space that should be under your local control. They could also be seen as a privacy issue by taking packets destined to 2002::/16 somewhere unexpected and off-continent.
I would expect even in the cases where it does work, it would be subject to the same challenges faced by people using VPN services (being blocked from your kids favorite streaming services) and much poorer performance than native IPv4.
There is also the problem noted by Wes George with 6to4 being used in DNS amplification, which may be interesting..
http://iepg.org/2018-03-18-ietf101/wes.pdf
I don’t believe most providers are intending to offer 6to4 as a global service. Even the large providers (eg: Comcast) seem to have disabled it ~4+ years ago. While I know there’s people on the internet that like to hang on to legacy things, this is one that should end. The networks and devices today no longer require this sort of transition technology, and the networks where it’s left won’t want it as it will be used for various bad things(tm).
- Jared
I don’t believe most providers are intending to offer 6to4 as a global service. Even the large providers (eg: Comcast) seem to have disabled it ~4+ years ago. While I know there’s people on the internet that like to hang on to legacy things, this is one that should end. The networks and devices today no longer require this sort of transition technology, and the networks where it’s left won’t want it as it will be used for various bad things(tm). At some point it transitions from being a legacy transition tool which you really shouldn't be using to being an attractive nuisance, or worse genuinely dangerous either for the sender or the receiver. personally I
On 6/18/18 6:18 PM, Jared Mauch wrote: think we've crossed that point and we have a responsibility to insure proper burial.
- Jared
Jared Mauch <jared@puck.nether.net> wrote:
There is also the problem noted by Wes George with 6to4 being used in DNS amplification, which may be interesting..
I configure my DNS servers with a long-ish list of bogon addresses. For v6, the list includes Teredo and 6to4 and various other horrors: # RFC 5156 and IANA IPv6 address space registry server 0000::/3 { bogus yes; }; server 2001:0000::/32 { bogus yes; }; server 2001:0002::/48 { bogus yes; }; server 2001:0010::/28 { bogus yes; }; server 2001:0db8::/32 { bogus yes; }; server 2002::/16 { bogus yes; }; server 3000::/4 { bogus yes; }; server 4000::/2 { bogus yes; }; server 8000::/1 { bogus yes; }; Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Southeast Iceland: Cyclonic, mainly westerly, 6 to gale 8, decreasing 5 later. Rough or very rough, becoming moderate or rough later. Showers. Moderate or good.
* marka@isc.org (Mark Andrews) [Tue 19 Jun 2018, 01:35 CEST]:
If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY.
Find me one site with a competent admin that deliberately publishes 2002::/16 in DNS.
None of the problems required removing it from BGP. There were end sites that had firewalls that blocked 6to4 responses and the odd site that ran a gateway and failed to properly manage it. The rest could have been dealt with by configuring more gateways.
Could. But hasn't. Right now it's merely a security risk. People who used to run a gateway and competently managed it took them down years ago when they, being competent admins, realised the utility had run out. -- Niels.
If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It they don’t want it all they have to do is withdraw the prefix. It is not up to the rest of us to second guess their decision to keep providing support. WG] I don't think that this is intentional in most cases anymore. It's most likely legacy cruft/zombie services. Because it mostly operates unattended and the few that are still using it probably don't notice when it breaks nor can they figure out to whom they should complain because anycast makes that nearly impossible, it continues operating quietly in the dusty and disused corners of the net below a sign saying "beware of the leopard" until the equipment gets retired or dies of old age. Also this argument would carry more weight if it hadn't already been had and concluded with RFC7526, and if it wasn't completely disabled on MS products now: https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803...
If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY. WG] As opposed to the unintentional denial-of-service attacks that happen all the time because of the inherent flaws in the implementation and the low importance people place on first-class deployments of this service? Sites that are still using it deliberately should have found a more reliable solution years ago, even if it's a statically-provisioned GRE or 6in4 tunnel. Plenty of tunnel brokers out there to facilitate
On 6/18/18 7:34 PM, Mark Andrews wrote: this if native IPv6 still isn't available. Keeping this around past its sell-by date is simply enabling bad behavior and a bad user experience for IPv6. Wes George
On 20 Jun 2018, at 4:16 am, Wes George <wesgeorge@puck.nether.net> wrote:
On 6/18/18 7:34 PM, Mark Andrews wrote:
If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It they don’t want it all they have to do is withdraw the prefix. It is not up to the rest of us to second guess their decision to keep providing support. WG] I don't think that this is intentional in most cases anymore. It's most likely legacy cruft/zombie services. Because it mostly operates unattended and the few that are still using it probably don't notice when it breaks nor can they figure out to whom they should complain because anycast makes that nearly impossible, it continues operating quietly in the dusty and disused corners of the net below a sign saying "beware of the leopard" until the equipment gets retired or dies of old age. Also this argument would carry more weight if it hadn't already been had and concluded with RFC7526, and if it wasn't completely disabled on MS products now: https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803...
If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY. WG] As opposed to the unintentional denial-of-service attacks that happen all the time because of the inherent flaws in the implementation and the low importance people place on first-class deployments of this service? Sites that are still using it deliberately should have found a more reliable solution years ago, even if it's a statically-provisioned GRE or 6in4 tunnel. Plenty of tunnel brokers out there to facilitate this if native IPv6 still isn't available. Keeping this around past its sell-by date is simply enabling bad behavior and a bad user experience for IPv6.
Actually there aren’t plenty of tunnel brokers anymore. Lots have shut up shop in the last couple of years. HE is still there but the others are gone or are not accepting new tunnels. At the moment I’m waiting for sane routing between HE and Optus to move my tunnel end point closer. Crossing the Pacific twice to get to HE’s pop in Sydney is insane. If I used it for IPv6 traffic there would be 6 crossing of the Pacific for most IPv6 traffic to get a IPv6 reply. That’s 4 more than there should be. I don’t expect Optus to offer IPv6 any time soon. Mark
Wes George
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Jun 19, 2018, at 8:03 PM, Mark Andrews <marka@isc.org> wrote:
On 20 Jun 2018, at 4:16 am, Wes George <wesgeorge@puck.nether.net> wrote:
On 6/18/18 7:34 PM, Mark Andrews wrote:
If a ASN is announcing 2002::/16 then they are are happy to get the traffic. It they don’t want it all they have to do is withdraw the prefix. It is not up to the rest of us to second guess their decision to keep providing support. WG] I don't think that this is intentional in most cases anymore. It's most likely legacy cruft/zombie services. Because it mostly operates unattended and the few that are still using it probably don't notice when it breaks nor can they figure out to whom they should complain because anycast makes that nearly impossible, it continues operating quietly in the dusty and disused corners of the net below a sign saying "beware of the leopard" until the equipment gets retired or dies of old age. Also this argument would carry more weight if it hadn't already been had and concluded with RFC7526, and if it wasn't completely disabled on MS products now: https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803...
If you filter 2002::/16 then you are performing a denial-of-service attack on the few sites that are still using it DELIBERATELY. WG] As opposed to the unintentional denial-of-service attacks that happen all the time because of the inherent flaws in the implementation and the low importance people place on first-class deployments of this service? Sites that are still using it deliberately should have found a more reliable solution years ago, even if it's a statically-provisioned GRE or 6in4 tunnel. Plenty of tunnel brokers out there to facilitate this if native IPv6 still isn't available. Keeping this around past its sell-by date is simply enabling bad behavior and a bad user experience for IPv6.
Actually there aren’t plenty of tunnel brokers anymore. Lots have shut up shop in the last couple of years. HE is still there but the others are gone or are not accepting new tunnels.
At the moment I’m waiting for sane routing between HE and Optus to move my tunnel end point closer. Crossing the Pacific twice to get to HE’s pop in Sydney is insane. If I used it for IPv6 traffic there would be 6 crossing of the Pacific for most IPv6 traffic to get a IPv6 reply. That’s 4 more than there should be.
I don’t expect Optus to offer IPv6 any time soon.
Vote with your wallet? Does Optus offer a good 6to4 gateway? Right now the 6to4 gateway I’m routed to is too far away to even make sense. Going from a US national eyeball provider to Prague isn’t the right solution either. At a previous job we tried to figure out if there was value in offering commercial IPv6 tunnels that would workaround some of the problems you speak of. The problem is the market wasn’t large enough to really justify it. I know a few folks working on offering some commercial IPv6 transition solutions, perhaps they would be willing to sell it to you or offer it for a freemium so you can provide feedback? I’d love to solve the physics problem for you as well, but that’s perhaps a bit harder. - Jared
participants (11)
-
Ca By -
Harald Koch -
j k -
Jared Mauch -
joel jaeggli -
John Kristoff -
Mark Andrews -
McBride, Mack -
Niels Bakker -
Tony Finch -
Wes George