TicketMaster / Live Nation admin on list?

[mike . lyon]

If so, can you contact me offlist? I seem to have a subnet that you guys don't 
like.

Thank You,
Mike

GoDaddy abuse Contact

[J Crowe]

Could someone from GoDaddy please contact me off list?  Running into issues
where customers on our network are not able to reach their sites due to
blackhole because of phishing sites that are on the shared IP.

Thanks
Joe Crowe
Comcast

Go Daddy contact

[Feldman, Mark]

Can someone from Go Daddy contact me off-list about a shared customer issue?

  Mark
  Comcast DNS

Re: BCP38 adoption "incentives"?

[Mark Andrews]

Even if the customers are unaware of the spoofed traffic, ISPs
should be aware which leaves them open for "aiding and abetting".
This doesn't require inspecting the payload of the packets.  This
is the IP header which they are expected to examine and for which
there is a BCP saying to drop spoofed packets.  Sources are used
for policy routing so the source field is expected to be processed.

I would expect a Judge to take into consideration the BCP in deciding
whether a ISP should be aware of the issue when deciding if a ISP
is aiding and abetting by allowing spoofed packets to enter their
network.

Mark

In message , Alain Hebert 
writes:
> Well there is money to be made in DDoS protection...  See our
> "friends" still hosting "those" pay sites.
> 
> Do not expect the vendors to cut themself of that market.
> 
> -
> 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
> 
> On 09/29/16 11:31, Leo Bicknell wrote:
> > In a message written on Tue, Sep 27, 2016 at 08:44:35PM +, White, 
> > Andrew wrote:
> >> This assumes the ISP manages the customer's CPE or home router, which is 
> >> often not the case. Adding such ACLs
>  to the upstream device, operated by the ISP, is not always easy or feasible.
> > Unicast RFP should be a feature every ISP requires of all edge
> > devices for at least 15 years now.  It should be on by default for
> > virtually all connections, and disabled only by request or when
> > there are circumstances to suggest it would break things (e.g. a
> > request for BGP with full tables over the link).
> >
> > At this point there's no excuse, anyone who has gear who can't do
> > that has been asleep at the switch.  It's been a standard feature
> > in too much gear for too long.
> >
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: bogon identified? how to track down bogus IPs/ASN's

[Blake Hudson]

As far as I can tell, AS394786 (Avetria Wireless) made up both AS135022 
and the associated bogon IP ranges that AS announces (103.206.16.0/22 & 
182.161.32.0/22) for its own use. Avetria's sole upstream provider 
appears to be AS54889 (Bluwest Inc). Probably an issue to discuss with 
both of these organizations.


--Blake

Filip Hruska wrote on 9/29/2016 3:06 PM:
According to HE's BGP tool, the IP range is actually 103.206.16.0/22 
and it looks like it's a bogon.


http://bgp.he.net/net/103.206.16.0/22#_bogon

Regards,
Filip

On 29.9.2016 21:46, Ken Chase wrote:

My turn for the newb question:

I've got a traceroute with this IP in it thats close to the end of 
the trace.


103.206.16.46

Chasing down this IP to see who the ISP a friend is using, figured out
the diff between ARIN and APNIC whois for IPs (..bit of a learning 
curve, not

sure why there's not just one whois interface syntax).

 whois -h whois.apnic.net -m 103.206.16.0/21

shows only the upper /22 being registered with APNIC (if you do -m on
.16.0/22, there's no entry).

So it seems to me these Ips arent registered properly with APNIC 
(could it
be cross-registered with another RIR? Well it's not with ARIN who'd 
be the local.)


But I do see this block in global bgp tables so it wasnt like someone 
decided to use
10.10.10/24 or 1.2.3/24 in their routing infrastructure. They're 
actually announcing;


 sh ip bg 103.206.16.0  ends in a path with  394786 135022

looking up 394786 I see avetria networks. looking up 135022 I see 
nothing at ARIN.


At APNIC I get

as-block:   AS134557 - AS135580
descr:  APNIC ASN block
remarks:These AS numbers are further assigned by APNIC
remarks:to APNIC members and end-users in the APNIC region

but nothing more specific.

However, this does show up in radb as avetria networks as well. (and 
various geolocate
DBs put it in Melbourn.au though i know it's in use in Kitchener 
ontario).


So what's not matching up here?

/kc
--
Ken Chase - m...@sizone.org Guelph Ontario

Re: bogon identified? how to track down bogus IPs/ASN's

[Filip Hruska]

According to HE's BGP tool, the IP range is actually 103.206.16.0/22 and 
it looks like it's a bogon.


http://bgp.he.net/net/103.206.16.0/22#_bogon

Regards,
Filip

On 29.9.2016 21:46, Ken Chase wrote:

My turn for the newb question:

I've got a traceroute with this IP in it thats close to the end of the trace.

103.206.16.46

Chasing down this IP to see who the ISP a friend is using, figured out
the diff between ARIN and APNIC whois for IPs (..bit of a learning curve, not
sure why there's not just one whois interface syntax).

 whois -h whois.apnic.net -m 103.206.16.0/21

shows only the upper /22 being registered with APNIC (if you do -m on
.16.0/22, there's no entry).

So it seems to me these Ips arent registered properly with APNIC (could it
be cross-registered with another RIR? Well it's not with ARIN who'd be the 
local.)

But I do see this block in global bgp tables so it wasnt like someone decided 
to use
10.10.10/24 or 1.2.3/24 in their routing infrastructure. They're actually 
announcing;

 sh ip bg 103.206.16.0  ends in a path with  394786 135022

looking up 394786 I see avetria networks. looking up 135022 I see nothing at 
ARIN.

At APNIC I get

as-block:   AS134557 - AS135580
descr:  APNIC ASN block
remarks:These AS numbers are further assigned by APNIC
remarks:to APNIC members and end-users in the APNIC region

but nothing more specific.

However, this does show up in radb as avetria networks as well. (and various 
geolocate
DBs put it in Melbourn.au though i know it's in use in Kitchener ontario).

So what's not matching up here?

/kc
--
Ken Chase - m...@sizone.org Guelph Ontario

PeeringDB Product Committee Charter Survey / NANOG

[Arnold Nipper]

Hello PeeringDB users / hello NANOG,

the PeeringDB Product Committee (PC, [0]) is charged with steering the
future product development and running the market outreach efforts to
continuously improve the value that PeeringDB delivers to the networks
registered with PeeringDB, and the broader community.

We're looking for feedback and input from the community on our charter
proposal. Please take this short survey [1]. Your input and comments are
appreciated!


[0] http://docs.peeringdb.com/gov/
[1] https://www.surveymonkey.com/r/JN36DT2


Greetings
Arnold
-- 
Arnold Nipper
email: arn...@nipper.de  phone: +49 6224 5593407 2
mobile: +49 172 2650958  fax:   +49 6224 5593407 9





signature.asc
Description: OpenPGP digital signature

bogon identified? how to track down bogus IPs/ASN's

[Ken Chase]

My turn for the newb question:

I've got a traceroute with this IP in it thats close to the end of the trace.

103.206.16.46

Chasing down this IP to see who the ISP a friend is using, figured out
the diff between ARIN and APNIC whois for IPs (..bit of a learning curve, not
sure why there's not just one whois interface syntax).

 whois -h whois.apnic.net -m 103.206.16.0/21 

shows only the upper /22 being registered with APNIC (if you do -m on
.16.0/22, there's no entry).

So it seems to me these Ips arent registered properly with APNIC (could it
be cross-registered with another RIR? Well it's not with ARIN who'd be the 
local.)

But I do see this block in global bgp tables so it wasnt like someone decided 
to use
10.10.10/24 or 1.2.3/24 in their routing infrastructure. They're actually 
announcing;

 sh ip bg 103.206.16.0  ends in a path with  394786 135022

looking up 394786 I see avetria networks. looking up 135022 I see nothing at 
ARIN.

At APNIC I get

as-block:   AS134557 - AS135580
descr:  APNIC ASN block
remarks:These AS numbers are further assigned by APNIC
remarks:to APNIC members and end-users in the APNIC region

but nothing more specific.

However, this does show up in radb as avetria networks as well. (and various 
geolocate
DBs put it in Melbourn.au though i know it's in use in Kitchener ontario).

So what's not matching up here?

/kc
--
Ken Chase - m...@sizone.org Guelph Ontario

contact @ detroit pistons IT/network org?

[david raistrick]

by chance -

anyone have a clueful contact at the detroit pistons who can help resolve
an https MITM proxy problem?  (likely a misconfigured watchguard.)

trying to diagnose a proxy level certificate problem through a management
level proxy is less than fun.

Re: Root Zone DNSSEC Operational Update -- ZSK length change

[Wessels, Duane]

A quick update on this change: A 2048-bit ZSK has been pre-published in the 
root zone as of September 20.  We are not aware of any issues related to the 
appearance of the larger key.

In less than 48 hours we will being publishing root zones signed with the 
2048-bit ZSK.  I will send another note once that has happened.  If you observe 
any problems related to this change, please contact Verisign's customer service 
at i...@verisign-grs.com.

Duane W.

> On Jul 28, 2016, at 3:37 PM, Wessels, Duane  wrote:
> 
> As you may know, Verisign, in its role as the Root Zone Maintainer
> is also the operator of the root zone Zone Signing Key (ZSK).  Later
> this year, we will increase the size of the ZSK from 1024-bits to
> 2048-bits.
> 
> The root zone ZSK is normally rolled every calendar quarter, as per
> our “DNSSEC Practice Statement for the Root Zone ZSK operator.”[1]
> The ZSK public keys are signed at quarterly key signing ceremonies
> by ICANN in its role as the IANA Functions Operator.
> 
> On September 20, 2016 the 2048-bit ZSK will be pre-published in the
> root zone, following the standard ZSK rollover procedure.  We intend
> to begin publishing root zones signed with the first 2048-bit ZSK
> on October 1, 2016.
> 
> Some details of the ZSK size transition have recently been presented
> at the DNS-OARC, NANOG, RIPE, ICANN, and IETF meetings.[2]  If you
> have any questions or concerns, please feel free to contact us at
> z...@verisign.com.
> 
> Please feel free to forward this message to anyone who might not have
> seen it here.
> 
> [1] https://www.verisign.com/assets/dps-zsk-operator-1532.pdf
> [2] 
> https://ripe72.ripe.net/wp-content/uploads/presentations/168-verisign-zsk-change.pdf
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: BCP38 adoption "incentives"?

[Alain Hebert]

Well there is money to be made in DDoS protection...  See our
"friends" still hosting "those" pay sites.

Do not expect the vendors to cut themself of that market.

-
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

On 09/29/16 11:31, Leo Bicknell wrote:
> In a message written on Tue, Sep 27, 2016 at 08:44:35PM +, White, Andrew 
> wrote:
>> This assumes the ISP manages the customer's CPE or home router, which is 
>> often not the case. Adding such ACLs to the upstream device, operated by the 
>> ISP, is not always easy or feasible.
> Unicast RFP should be a feature every ISP requires of all edge
> devices for at least 15 years now.  It should be on by default for
> virtually all connections, and disabled only by request or when
> there are circumstances to suggest it would break things (e.g. a
> request for BGP with full tables over the link).
>
> At this point there's no excuse, anyone who has gear who can't do
> that has been asleep at the switch.  It's been a standard feature
> in too much gear for too long.
>

Re: BCP38 adoption "incentives"?

[Leo Bicknell]

In a message written on Tue, Sep 27, 2016 at 08:44:35PM +, White, Andrew 
wrote:
> This assumes the ISP manages the customer's CPE or home router, which is 
> often not the case. Adding such ACLs to the upstream device, operated by the 
> ISP, is not always easy or feasible.

Unicast RFP should be a feature every ISP requires of all edge
devices for at least 15 years now.  It should be on by default for
virtually all connections, and disabled only by request or when
there are circumstances to suggest it would break things (e.g. a
request for BGP with full tables over the link).

At this point there's no excuse, anyone who has gear who can't do
that has been asleep at the switch.  It's been a standard feature
in too much gear for too long.

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


pgpsnqYUh9bKQ.pgp
Description: PGP signature