Re: Apple devices spoofing default gateway?

[Matt Freitag]

For those of us with Aruba wireless, www boy, could you share some more
info about your setup/code version/configuration/specific APs/controller
model(s)/etc?

Matt Freitag
Network Engineer
Michigan Tech IT
Michigan Technological University

We can help.
mtu.edu/it
(906) 487-


On Fri, Jun 7, 2019 at 3:06 PM Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:

> Turn on client isolation on the access points?
>
> > On Jun 7, 2019, at 3:00 PM, Hugo Slabbert  wrote:
> >
> >
> >> On Fri 2019-Jun-07 16:21:29 +1000, www boy  wrote:
> >>
> >> I just joined nanog to allow me to respond to a thread that Simon
> posted in
> >> March. .
> >> (Not sure if this is how to respond)
> >>
> >> We have the exact same problem with Aruba Access points and with
> multiple
> >> MacBooks and a iMac.
> >> Where the device will spoof the default gateway and the effect is that
> vlan
> >> is not usable.
> >>
> >> I also have raised a case with Apple but so far no luck.
> >>
> >> What is the status of your issue?  Any luck working out exactly what the
> >> cause is?
> >
> > We appeared to hit this with Cisco kit:
> >
> https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html
> >
> > They don't say *exactly* that the Apple devices are spoofing the
> gateway, but some behaviour in what they send out results in the proxy arp
> being performed by the APs to update the ARP entry for the gateway address
> to the clients':
> >
> >> * This is not a malicious attack, but triggered by an interaction
> between the macOS device while in sleeping mode, and specific broadcast
> traffic generated by newer Android devices
> >> * AP-COS while in FlexConnect mode provides Proxy ARP (ARP caching)
> services by default.  Due to their address learning design, they will
> modify table entries based on this traffic leading to default gateway ARP
> entry modification
> >
> > The fix was to disable ARP caching on the APs so they don't proxy ARP
> but ARP replies pass directly between client devices.
> >
> > --
> > Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> > pgp key: B178313E   | also on Signal
>

Re: Apple devices spoofing default gateway?

[William Herrin]

On Fri, Jun 7, 2019 at 6:14 AM www boy  wrote:
> I just joined nanog to allow me to respond to a thread that Simon posted
in March. .
> (Not sure if this is how to respond)
>
> We have the exact same problem with Aruba Access points and with multiple
MacBooks and a iMac.
> Where the device will spoof the default gateway and the effect is that
vlan is not usable.
>
> I also have raised a case with Apple but so far no luck.
>
> What is the status of your issue?  Any luck working out exactly what the
cause is?


Hmm. Shooting in the dark here, but do you have a mismatch in your netmask
configurations? A device configured to perform proxy arp may respond to
requests for addresses outside its configured netmask. If the configured
address and netmask for some reason excluded the default gateway... Or if,
say, you have multiple subnets on the same vlan and one of the devices in
one of the subnets is configured to perform proxy arp...


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Apple devices spoofing default gateway?

[Owen DeLong]

This is a less than helpful feature in a lot of situations…

e.g. I was attempting to work on an IOT device and test OTA firmware updates in 
a Hotel a little while ago.

The client isolation on the wifi network resulted in non-obvious failures that 
took some time to identify.

In general, people expect communications within a LAN segment to work. Breaking 
this assumption should only be done in cases where there is very good reason to 
do so.

I fully appreciate the argument that a hotel WiFi is one such situation and 
even agree with it to some extent. However, in such circumstances, I believe 
the fact should be posted in plain view and/or noticed on the captive portal 
login page.

Owen


> On Jun 7, 2019, at 12:06 , Matt Hoppes  
> wrote:
> 
> Turn on client isolation on the access points?
> 
>> On Jun 7, 2019, at 3:00 PM, Hugo Slabbert  wrote:
>> 
>> 
>>> On Fri 2019-Jun-07 16:21:29 +1000, www boy  wrote:
>>> 
>>> I just joined nanog to allow me to respond to a thread that Simon posted in
>>> March. .
>>> (Not sure if this is how to respond)
>>> 
>>> We have the exact same problem with Aruba Access points and with multiple
>>> MacBooks and a iMac.
>>> Where the device will spoof the default gateway and the effect is that vlan
>>> is not usable.
>>> 
>>> I also have raised a case with Apple but so far no luck.
>>> 
>>> What is the status of your issue?  Any luck working out exactly what the
>>> cause is?
>> 
>> We appeared to hit this with Cisco kit:
>> https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html
>> 
>> They don't say *exactly* that the Apple devices are spoofing the gateway, 
>> but some behaviour in what they send out results in the proxy arp being 
>> performed by the APs to update the ARP entry for the gateway address to the 
>> clients':
>> 
>>> * This is not a malicious attack, but triggered by an interaction between 
>>> the macOS device while in sleeping mode, and specific broadcast traffic 
>>> generated by newer Android devices
>>> * AP-COS while in FlexConnect mode provides Proxy ARP (ARP caching) 
>>> services by default.  Due to their address learning design, they will 
>>> modify table entries based on this traffic leading to default gateway ARP 
>>> entry modification
>> 
>> The fix was to disable ARP caching on the APs so they don't proxy ARP but 
>> ARP replies pass directly between client devices.
>> 
>> -- 
>> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
>> pgp key: B178313E   | also on Signal

Re: Networks enforcing RPKI validation

[Mark Tinka]

On 7/Jun/19 16:58, Eric Dugas wrote:

> Hello NANOG,
>
> I was wondering if there was a list of networks that enforce RPKI
> validation and dropping invalids.

In Africa, we (SEACOM - AS37100) and Workonline (AS37271) have had it
enabled since April this year.

>
> The shortlist I know is: AT&T (since February of this year) and of
> course NTT because of Job

AFAIK, NTT aren't doing it yet, but plan to soon.

Mark.

Re: Apple devices spoofing default gateway?

[Matt Hoppes]

Turn on client isolation on the access points?

> On Jun 7, 2019, at 3:00 PM, Hugo Slabbert  wrote:
> 
> 
>> On Fri 2019-Jun-07 16:21:29 +1000, www boy  wrote:
>> 
>> I just joined nanog to allow me to respond to a thread that Simon posted in
>> March. .
>> (Not sure if this is how to respond)
>> 
>> We have the exact same problem with Aruba Access points and with multiple
>> MacBooks and a iMac.
>> Where the device will spoof the default gateway and the effect is that vlan
>> is not usable.
>> 
>> I also have raised a case with Apple but so far no luck.
>> 
>> What is the status of your issue?  Any luck working out exactly what the
>> cause is?
> 
> We appeared to hit this with Cisco kit:
> https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html
> 
> They don't say *exactly* that the Apple devices are spoofing the gateway, but 
> some behaviour in what they send out results in the proxy arp being performed 
> by the APs to update the ARP entry for the gateway address to the clients':
> 
>> * This is not a malicious attack, but triggered by an interaction between 
>> the macOS device while in sleeping mode, and specific broadcast traffic 
>> generated by newer Android devices
>> * AP-COS while in FlexConnect mode provides Proxy ARP (ARP caching) services 
>> by default.  Due to their address learning design, they will modify table 
>> entries based on this traffic leading to default gateway ARP entry 
>> modification
> 
> The fix was to disable ARP caching on the APs so they don't proxy ARP but ARP 
> replies pass directly between client devices.
> 
> -- 
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal

Re: Apple devices spoofing default gateway?

[Hugo Slabbert]

On Fri 2019-Jun-07 16:21:29 +1000, www boy  wrote:


I just joined nanog to allow me to respond to a thread that Simon posted in
March. .
(Not sure if this is how to respond)

We have the exact same problem with Aruba Access points and with multiple
MacBooks and a iMac.
Where the device will spoof the default gateway and the effect is that vlan
is not usable.

I also have raised a case with Apple but so far no luck.

What is the status of your issue?  Any luck working out exactly what the
cause is?


We appeared to hit this with Cisco kit:
https://www.cisco.com/c/en/us/support/docs/wireless/aironet-3800-series-access-points/214491-arp-responses-for-default-gateway-ip-add.html

They don't say *exactly* that the Apple devices are spoofing the gateway, 
but some behaviour in what they send out results in the proxy arp being 
performed by the APs to update the ARP entry for the gateway address to the 
clients':


* This is not a malicious attack, but triggered by an interaction between 
the macOS device while in sleeping mode, and specific broadcast traffic 
generated by newer Android devices


* AP-COS while in FlexConnect mode provides Proxy ARP (ARP caching) 
services by default.  Due to their address learning design, they will 
modify table entries based on this traffic leading to default gateway ARP 
entry modification


The fix was to disable ARP caching on the APs so they don't proxy ARP but 
ARP replies pass directly between client devices.


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


signature.asc
Description: Digital signature

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 08 Jun, 2019

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  757473
Prefixes after maximum aggregation (per Origin AS):  291275
Deaggregation factor:  2.60
Unique aggregates announced (without unneeded subnets):  362403
Total ASes present in the Internet Routing Table: 64457
Prefixes per ASN: 11.75
Origin-only ASes present in the Internet Routing Table:   55455
Origin ASes announcing only one prefix:   23832
Transit ASes present in the Internet Routing Table:9002
Transit-only ASes present in the Internet Routing Table:275
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  42
Max AS path prepend of ASN ( 27978)  31
Prefixes from unregistered ASNs in the Routing Table:25
Number of instances of unregistered ASNs:28
Number of 32-bit ASNs allocated by the RIRs:  27264
Number of 32-bit ASNs visible in the Routing Table:   22288
Prefixes from 32-bit ASNs in the Routing Table:  100069
Number of bogon 32-bit ASNs visible in the Routing Table:20
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:246
Number of addresses announced to Internet:   2839509120
Equivalent to 169 /8s, 63 /16s and 120 /24s
Percentage of available address space announced:   76.7
Percentage of allocated address space announced:   76.7
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.3
Total number of prefixes smaller than registry allocations:  252705

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   204836
Total APNIC prefixes after maximum aggregation:   60878
APNIC Deaggregation factor:3.36
Prefixes being announced from the APNIC address blocks:  200984
Unique aggregates announced from the APNIC address blocks:83016
APNIC Region origin ASes present in the Internet Routing Table:9790
APNIC Prefixes per ASN:   20.53
APNIC Region origin ASes announcing only one prefix:   2717
APNIC Region transit ASes present in the Internet Routing Table:   1468
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   4794
Number of APNIC addresses announced to Internet:  772705920
Equivalent to 46 /8s, 14 /16s and 142 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-139577
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:225582
Total ARIN prefixes after maximum aggregation:   105116
ARIN Deaggregation factor: 2.15
Prefixes being announced from the ARIN address blocks:   224535
Unique aggregates announced from the ARIN address blocks:105850
ARIN Region origin ASes present in the Internet Routing Table:18490
ARIN Prefixes per ASN:12.14
ARIN Regio

Re: CenturyLink/Level 3 combined AS

[Brielle Bruns]

On 6/7/2019 11:03 AM, Romeo Czumbil wrote:

All new CL Internet get's provisioned on AS3356
You would need a strong case for them to put you on AS209



Got provisioned last year on AS209 when they turned up my ent Fiber with 
BGP.


Could depend heavily on what services and where.

--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: CenturyLink/Level 3 combined AS

[Eric Flanery (eric)]

On Fri, Jun 7, 2019 at 10:03 AM Romeo Czumbil 
wrote:

> All new CL Internet get's provisioned on AS3356
> You would need a strong case for them to put you on AS209
>
> At this time they are not merging the two AS's
> And also define "quality" ;-)
>
> -Romeo
>

That isn't true in my recent experience. We just replaced an older L3
transit with a new CL one on different floors of the same building, and
doing so involved moving from 3356 to 209.

Interestingly, the CFA for the new circuit's attachment suggests it came
out of the "L3" suite, not the "Qwest" suite (both on the same floor); so
it seems that 209 is provision-able at former L3 facilities.

Other recent entirely new CL turn-ups with us, out of rural COs belonging
to Frontier, have also been with 209.

--Eric

RE: CenturyLink/Level 3 combined AS

[Romeo Czumbil]

All new CL Internet get's provisioned on AS3356
You would need a strong case for them to put you on AS209

At this time they are not merging the two AS's
And also define "quality" ;-)

-Romeo

From: NANOG  On Behalf Of Darin Steffl
Sent: Friday, June 7, 2019 12:02 PM
To: North American Network Operators' Group 
Subject: CenturyLink/Level 3 combined AS

Hey all,

Are there plans for CL and Level3 to combine AS's into one network? 

If not, do they actively peer and route traffic through each other's networks 
at least?

Basically we're looking at picking up 1G of CL and wondering if it's near the 
same quality as Level3 in terms of latency and packet loss.

Thanks


-- 
Darin Steffl
Minnesota WiFi
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mnwifi.com_&d=DwMFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=B9x15ZQ8isrQ6IfUsWLNMps3Fxkm9knEK_q5EDIUVEU&s=cOxvX4Mpm1zNu7Y2hWKKzjTiR12MNhBseyGKijwODv4&e=
507-634-WiFi
 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.facebook.com_minnesotawifi&d=DwMFaQ&c=QbKJOwLIrSFJ6b5qo-Piqw&r=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE&m=B9x15ZQ8isrQ6IfUsWLNMps3Fxkm9knEK_q5EDIUVEU&s=mWRM-1yVsEZInKW4u3DeFnLdPW_gwkA7GbTvFdccydI&e=

Re: CenturyLink/Level 3 combined AS

[Tom Beecher]

That '2000 peer ASN's' value is likely very, very inflated. I have prefixes
that would look like I am peering with 3549 directly in many places that I
do not.

L3 has for some time had a partial as-merge community that you can set so
that if you announce a prefix to 3356, they'll mirror it over to 3549 in
the same location and strip 3356 from the as-path. The reverse also works
for an announcement to 3549 mirrored over to 3356. They're doing some
inter-as option c juju to make all that work.

Doesn't change the point that 3549 is still around 8 years later and likely
will be for 8 more, but yeah. :) I'm sure efforts to make that happen have
a plethora of roadblocks such that it would cost 10x more to get rid of it
than it would to just leave it as is and just shrink it when possible.

On Fri, Jun 7, 2019 at 12:11 PM Mike Hammett  wrote:

> I wouldn't expect them to be integrated for at least another decade.
> Global Crossing AS3549 still exists with over 2,000 peer ASNs, yet Level 3
> acquired them in 2011. Time Warner Telecom was acquired in 2014 and it
> still has 89 peer ASNs.
>
> Centurylink bought Digital Teleport in 2003 and their ASN is still out
> there.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Darin Steffl" 
> *To: *"North American Network Operators' Group" 
> *Sent: *Friday, June 7, 2019 11:01:46 AM
> *Subject: *CenturyLink/Level 3 combined AS
>
> Hey all,
>
> Are there plans for CL and Level3 to combine AS's into one network?
>
> If not, do they actively peer and route traffic through each other's
> networks at least?
>
> Basically we're looking at picking up 1G of CL and wondering if it's near
> the same quality as Level3 in terms of latency and packet loss.
>
> Thanks
>
> --
> Darin Steffl
> Minnesota WiFi
> www.mnwifi.com
> 507-634-WiFi
>  Like us on Facebook
> 
>
>

Re: CenturyLink/Level 3 combined AS

[Chris Adams]

Once upon a time, Darin Steffl  said:
> Are there plans for CL and Level3 to combine AS's into one network?

We have CenturyLink transit from old Qwest (AS 209) and old Level3 (AS
3356) in Chicago... when we ordered the more recent circuit, both sales
and tech said that there's no plan to merge the ASes together at this
time.  They already had peering, so I assume that just expanded.  We
haven't had any issues with either.

And BTW: when you say "CL" - those are just two of the large family of
ASes that CL has bought.  There's also old Savvis AS 6347, and other old
Savvis (aka Cable & Wireless aka InternetMCI) AS 3561, and untold more
Internet history... :)

-- 
Chris Adams 

Re: CenturyLink/Level 3 combined AS

[Mike Hammett]

I wouldn't expect them to be integrated for at least another decade. Global 
Crossing AS3549 still exists with over 2,000 peer ASNs, yet Level 3 acquired 
them in 2011. Time Warner Telecom was acquired in 2014 and it still has 89 peer 
ASNs. 


Centurylink bought Digital Teleport in 2003 and their ASN is still out there. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Darin Steffl"  
To: "North American Network Operators' Group"  
Sent: Friday, June 7, 2019 11:01:46 AM 
Subject: CenturyLink/Level 3 combined AS 


Hey all, 


Are there plans for CL and Level3 to combine AS's into one network? 


If not, do they actively peer and route traffic through each other's networks 
at least? 


Basically we're looking at picking up 1G of CL and wondering if it's near the 
same quality as Level3 in terms of latency and packet loss. 


Thanks 


-- 


Darin Steffl 
Minnesota WiFi 
www.mnwifi.com 
507-634-WiFi 
Like us on Facebook 

CenturyLink/Level 3 combined AS

[Darin Steffl]

Hey all,

Are there plans for CL and Level3 to combine AS's into one network?

If not, do they actively peer and route traffic through each other's
networks at least?

Basically we're looking at picking up 1G of CL and wondering if it's near
the same quality as Level3 in terms of latency and packet loss.

Thanks

-- 
Darin Steffl
Minnesota WiFi
www.mnwifi.com
507-634-WiFi
 Like us on Facebook

Re: Networks enforcing RPKI validation

[Job Snijders]

Dear Eric,

If you don't mind me showering you with some study resources... here we
go!

On Fri, Jun 07, 2019 at 10:58:48AM -0400, Eric Dugas wrote:
> I was wondering if there was a list of networks that enforce RPKI
> validation and dropping invalids.

The last list that was compiled is available here
https://blog.benjojo.co.uk/post/state-of-rpki-in-2018

I expect that by now the list has doubled. We received many anecdotal
reports since then from people having deployed Origin Validation in
their networks. Perhaps if we ask Ben Cartwright-Cox nice enough he can
run a new report for Q2 2019 :-)

> The shortlist I know is: AT&T (since February of this year) 

Which is awesome! AT&T's deployment has definitely lowered the barrier
to deployment for others.

> and of course NTT because of Job

Point of clarificartion: NTT is not there yet, but we are on our way.
NTT does not yet apply RFC 6811 Origin Validation on its EBGP session
and does not yet reject RPKI Invalid BGP announcements.

However, NTT does use RPKI data in its filter generation process, more
information on that topic can be found here:
https://blog.apnic.net/2018/08/01/treating-rpki-roas-as-irr-route6-objects/

The next step will be to use RPKI data to ignore conflicting IRR data,
this way the IRR will be harder to abuse in facilitating
misconfigurations or hijacks. An example of that type of use of RPKI
data can be found here https://ripe78.ripe.net/archives/video/119/
slides: 
https://ripe78.ripe.net/presentations/137-db_wg_ripe78_prop2018-06_snijders.pdf

After that, we'll also use RPKI data to strengthen our EBGP filters in a
similar way to how AT&T does it. I hope that we'll be done Q1 2020 - but
don't hold me to that date! We move at telco speed sometimes ;-)

An overview of where the industry was and where we're heading can be
found in "Routing Security Roadmap" presentation at
https://nlnog.net/nlnog-day-2018/

Finally - here is a quick and easy browser based tool to attempt to
figure out if the network you are connected to performs RPKI based BGP
Origin Validation (and is default-free) https://ripe.net/s/rpki-test

Kind regards,

Job

Networks enforcing RPKI validation

[Eric Dugas]

Hello NANOG,

I was wondering if there was a list of networks that enforce RPKI
validation and dropping invalids.

The shortlist I know is: AT&T (since February of this year) and of course
NTT because of Job

Thanks
Eric

Re: Apple devices spoofing default gateway?

[www boy]

I just joined nanog to allow me to respond to a thread that Simon posted in
March. .
(Not sure if this is how to respond)

We have the exact same problem with Aruba Access points and with multiple
MacBooks and a iMac.
Where the device will spoof the default gateway and the effect is that vlan
is not usable.

I also have raised a case with Apple but so far no luck.

What is the status of your issue?  Any luck working out exactly what the
cause is?

Regards,
Mike