Re: Do ISP's collect and analyze traffic of users?

[Michael Thomas]

On 5/19/23 6:09 AM, Justin Streiner wrote:

Hank:

No doubt there is a massive amount of information that can be gathered 
from in-box telemetry.  This thread appears to be more focused on 
providers gathering data from traffic in flight across their 
infrastructure.


Yeah, my curiosity was whether ISP were trying to get in the monetizing 
traffic analysis biz which seems to be a small degree but they can't 
really compete with the much finer grained information that other means 
can provide and that they have no particular expertise in it or an 
institutional desire. For things like Google and Facebook, that kind of 
analysis was part of their initial business plan.


Mike



Thank you
jms

On Fri, May 19, 2023 at 8:49 AM Hank Nussbacher  
wrote:


On 19/05/2023 15:27, Justin Streiner wrote:

It amazes me how people can focus on Netflow metadata and ignore
things
like Microsoft telemetry data from every Windows box, or ignore the
massive amount of html cookies that are traded by companies or how
almost every corporate firewall or anti-spam box "reports" back to
the
mother ship and sends tons of information via secret channels like
hashed DNS lookups just to be avoided.

Regards,
Hank

> There are already so many different ways that organizations can
find
> out all sorts of information about individual users, as others have
> noted (social media interactions, mobile location/GPS data,
call/text
> history, interactions with specific sites, etc), that there
probably
> isn't much incentive for many providers to harvest data beyond
what is
> needed for troubleshooting and capacity planning.  Plus, gathering
> more data - potentially down to the level packet payload - is
not an
> easy problem to solve (read: expensive) and doesn't scale well
at all.
> 100G links are very common today, and 400G is becoming so.  I doubt
> that many infrastructure providers would be able to justify the
major
> investments in extra infrastructure to support this, for a revenue
> stream that likely wouldn't match that investment, which would make
> such an investment a loss-leader.
>
> Content providers - particularly social media platforms - have a
> somewhat different business model, but those providers already have
> many different ways to harvest and sell large troves of user data.
>
> Thank you
> jms

Fw: [Sidrops] Estimating timeline for ASPA Deployment

[Job Snijders via NANOG]

Heya NANOG,

I thought this email conversation might be of interest to the group:
https://mailarchive.ietf.org/arch/msg/sidrops/RdbccLbXEHUrmmdIS5K9GOdJFXA/

Kind regards,

Job

- Forwarded message from Job Snijders  -

Date: Fri, 19 May 2023 20:54:26 +0200
From: Job Snijders 
To: sidr...@ietf.org
Subject: Re: [Sidrops] Estimating timeline for ASPA Deployment

Dear Tony,

On Fri, May 19, 2023 at 10:18:58AM -0400, Tony Tauber wrote:
> I wonder what people think of likely soonest target dates for adoption
> of ASPA?

... Where do psychics go to dance?
 The crystal ball ;-) ...

Disclaimer: The following is based on unsubstantiated information and/or
my gutfeeling, I can't vouch for accuracy.

I'd like to share some information categorized as 'here work needs to be
done', a timeline, and a conclusion referencing earlier RPKI
experiences.

What needs to happen where?
---

There are a few categories of 'moving parts' in the global Internet
routing system that need upgrades in order for ASPA to see widespread
adoption.

Category  | (Non-exhaustive) list of implementations
--+--
Relaying Party packages:   OpenBSD rpki-client, NLnet Labs Routinator,
   LACNIC/NicMX FORT, Cloudflare octorpki,
   Mikhail Puzanov's rpki-prover, ZDNS RPSTIR2.

Signer implementations:NLnet Labs Krill, Dragon Labs rpki.net, and a
   number of Regional Internet Registries (RIRs)
   have their own in-house Signer solution.

BGP implementations:   OpenBSD OpenBGPD, NIC.CZ BIRD, FRRouting,
   Nokia SR-OS, Cisco IOS XR, Juniper Junos, and
   many others, see the 'BGP speakers' list at:
   http://largebgpcommunities.net/implementations/

Standalone RTR servers:StayRTR, NLnet Labs RTRTR, GoRTR, rpkirtr
Integrated RTR servers:FORT, Routinator

In order for there to be any ASPA deployment, at least one ASPA-capable
implementation in all of the RP, Signer, and BGP categories is needed.

Without a Signer there isn't anything for the RP to validate, without an
RP there isn't any for the BGP speaker to verify BGP UPDATEs against.
This is a great example of why the IETF process is so valuable: this
process has brought together many stakeholders from different corners of
the ecosystem each with different roles to jointly develop a solution
for BGP route leaks.

Timeline


2023 - "the early wave": ASPA support arrives in select BGP, RP, RTR,
   and Signer implementations.

   At the moment of writing OpenBSD rpki-client & OpenBGPD; NLnet
   Labs Routinator, Krill & RTRTR, StayRTR, rpki-prover, and RIPE
   NCC have either already released ASPA-capable software or are in
   an advanced stage to do so.

   These 'early wave' implementations are incredible achievements as
   there weren't any examples for the developers to look at, they
   were building across unchartered territory.

   One Internet Exchange Point managed to deploy fully ASPA-capable
   Route Server stack using bleeding edge software, however this
   effort should be considered an outliner from a timeline perspective:
   https://mailman.nanog.org/pipermail/nanog/2023-February/221471.html

2024 - The IETF ratifies ASPA by publishing a series of RFC documents
   detailing the specification. While SIDROPS (this working group)
   at this moment in time is in the late stages of specifying the
   ASPA standard, the Internet Engineering Steering Group (IESG) and
   RFC Editor still need to review the draft documents; all in all
   this might take another 6-10 months (from now).

   BGP monitoring software such as BGPAlerter and BGP.Tools might
   take an interest and start using ASPA data to enhance their
   alerting capabilities: a growing amount of ASPA data (which can
   be used to identify route leaks) is becoming available through
   the 'delegated' (permissionless) RPKI distribution channels.

2025 - Having access to both published RFCs and multiple battle-tested
   RP implementations (which originated in the 'early wave'), more
   and more RIRs will feel comfortable scheduling and committing
   development time to productize an ASPA-offering for their
   respective RPKI dashboard/web portal/api services.

   Why 2025? RIRs oftentimes are somewhat conservative and like to
   see which way the wind blows before offering new services to
   their constitutes. This is very understandable as for an RIR to
   offer ASPA the work involved is significantly more than just
   developing the technical Signer software. RIRs need to design
   (web-based) user interfaces, which is a big hurdle because for
   the first time ever RIRs 

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 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 https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 20 May, 2023

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  924080
Prefixes after maximum aggregation (per Origin AS):  349822
Deaggregation factor:  2.64
Unique aggregates announced (without unneeded subnets):  449331
Total ASes present in the Internet Routing Table: 74455
Prefixes per ASN: 12.41
Origin-only ASes present in the Internet Routing Table:   63908
Origin ASes announcing only one prefix:   26264
Transit ASes present in the Internet Routing Table:   10547
Transit-only ASes present in the Internet Routing Table:432
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  55
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:  1074
Number of instances of unregistered ASNs:  1075
Number of 32-bit ASNs allocated by the RIRs:  41898
Number of 32-bit ASNs visible in the Routing Table:   34608
Prefixes from 32-bit ASNs in the Routing Table:  171767
Number of bogon 32-bit ASNs visible in the Routing Table:15
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:622
Number of addresses announced to Internet:   3057966848
Equivalent to 182 /8s, 68 /16s and 223 /24s
Percentage of available address space announced:   82.6
Percentage of allocated address space announced:   82.6
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.6
Total number of prefixes smaller than registry allocations:  308506

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   245522
Total APNIC prefixes after maximum aggregation:   69449
APNIC Deaggregation factor:3.54
Prefixes being announced from the APNIC address blocks:  239730
Unique aggregates announced from the APNIC address blocks:98339
APNIC Region origin ASes present in the Internet Routing Table:   13441
APNIC Prefixes per ASN:   17.84
APNIC Region origin ASes announcing only one prefix:   3959
APNIC Region transit ASes present in the Internet Routing Table:   1799
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   8741
Number of APNIC addresses announced to Internet:  773621376
Equivalent to 46 /8s, 28 /16s and 134 /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-151865
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:269926
Total ARIN prefixes after maximum aggregation:   122680
ARIN Deaggregation factor: 2.20
Prefixes being announced from the ARIN address blocks:   272754
Unique aggregates announced from the ARIN address blocks:130386
ARIN Region origin ASes present in the Internet Routing Table:19115
ARIN Prefixes per ASN:   

Re: Do ISP's collect and analyze traffic of users?

[Justin Streiner]

Hank:

No doubt there is a massive amount of information that can be gathered from
in-box telemetry.  This thread appears to be more focused on providers
gathering data from traffic in flight across their infrastructure.

Thank you
jms

On Fri, May 19, 2023 at 8:49 AM Hank Nussbacher 
wrote:

> On 19/05/2023 15:27, Justin Streiner wrote:
>
> It amazes me how people can focus on Netflow metadata and ignore things
> like Microsoft telemetry data from every Windows box, or ignore the
> massive amount of html cookies that are traded by companies or how
> almost every corporate firewall or anti-spam box "reports" back to the
> mother ship and sends tons of information via secret channels like
> hashed DNS lookups just to be avoided.
>
> Regards,
> Hank
>
> > There are already so many different ways that organizations can find
> > out all sorts of information about individual users, as others have
> > noted (social media interactions, mobile location/GPS data, call/text
> > history, interactions with specific sites, etc), that there probably
> > isn't much incentive for many providers to harvest data beyond what is
> > needed for troubleshooting and capacity planning.  Plus, gathering
> > more data - potentially down to the level packet payload - is not an
> > easy problem to solve (read: expensive) and doesn't scale well at all.
> > 100G links are very common today, and 400G is becoming so.  I doubt
> > that many infrastructure providers would be able to justify the major
> > investments in extra infrastructure to support this, for a revenue
> > stream that likely wouldn't match that investment, which would make
> > such an investment a loss-leader.
> >
> > Content providers - particularly social media platforms - have a
> > somewhat different business model, but those providers already have
> > many different ways to harvest and sell large troves of user data.
> >
> > Thank you
> > jms
>
>

Re: Do ISP's collect and analyze traffic of users?

[Hank Nussbacher]

On 19/05/2023 15:27, Justin Streiner wrote:

It amazes me how people can focus on Netflow metadata and ignore things 
like Microsoft telemetry data from every Windows box, or ignore the 
massive amount of html cookies that are traded by companies or how 
almost every corporate firewall or anti-spam box "reports" back to the 
mother ship and sends tons of information via secret channels like 
hashed DNS lookups just to be avoided.


Regards,
Hank

There are already so many different ways that organizations can find 
out all sorts of information about individual users, as others have 
noted (social media interactions, mobile location/GPS data, call/text 
history, interactions with specific sites, etc), that there probably 
isn't much incentive for many providers to harvest data beyond what is 
needed for troubleshooting and capacity planning.  Plus, gathering 
more data - potentially down to the level packet payload - is not an 
easy problem to solve (read: expensive) and doesn't scale well at all. 
100G links are very common today, and 400G is becoming so.  I doubt 
that many infrastructure providers would be able to justify the major 
investments in extra infrastructure to support this, for a revenue 
stream that likely wouldn't match that investment, which would make 
such an investment a loss-leader.


Content providers - particularly social media platforms - have a 
somewhat different business model, but those providers already have 
many different ways to harvest and sell large troves of user data.


Thank you
jms

Re: [EXT] Dominican Republic Landing Station

[Thomas E Everett]

Puerto plata


https://www.fiberatlantic.com/cls/MQDB



Thomas E Everett

Principal Systems Engineer
The MITRE Corp


From: NANOG  on behalf of Robert 
DeVita 
Sent: Thursday, May 18, 2023 8:14:29 PM
To: nanog@nanog.org 
Subject: [EXT] Dominican Republic Landing Station


Does anyone have the address to the Cable Landing Station in Dominican 
Republic. I am told there is only 1 and I believe its in Punta Cana. Yes I 
spent 25 minutes trying to google it. Any help would be appreciated



Thanks



[cid:image001.jpg@01D989BC.76276310]

Robert DeVita

CEO and Founder

t: (469) 581-2160

 |

m: (469) 441-8864

e: radev...@mejeticks.com

 |

w: mejeticks.com

a:

3100 Carlisle St

,

Dallas

,

75204

[cid:image002.png@01D989BC.76276310]

[cid:image003.png@01D989BC.76276310]

[cid:image004.png@01D989BC.76276310]

Wave out of St Louis to Ashburn

[Louis Alexander via NANOG]

I have been looking for a wave (100g) provider that has a path between St Louis 
and Ashburn that avoids Dallas, Atlanta and Chicago. i.e. through the middle

Struggling to find this on any public network maps.

Please respond off list if you're aware of any options here.

Regards,
Louis

Re: Do ISP's collect and analyze traffic of users?

[Justin Streiner]

There are already so many different ways that organizations can find out
all sorts of information about individual users, as others have noted
(social media interactions, mobile location/GPS data, call/text history,
interactions with specific sites, etc), that there probably isn't much
incentive for many providers to harvest data beyond what is needed for
troubleshooting and capacity planning.  Plus, gathering more data -
potentially down to the level packet payload - is not an easy problem to
solve (read: expensive) and doesn't scale well at all. 100G links are very
common today, and 400G is becoming so.  I doubt that many infrastructure
providers would be able to justify the major investments in extra
infrastructure to support this, for a revenue stream that likely wouldn't
match that investment, which would make such an investment a loss-leader.

Content providers - particularly social media platforms - have a somewhat
different business model, but those providers already have many different
ways to harvest and sell large troves of user data.

Thank you
jms

On Tue, May 16, 2023 at 3:44 PM Matthew Petach 
wrote:

>
>
> On Tue, May 16, 2023 at 1:10 AM Jeroen Massar  wrote:
>
>>
>>
>> > On 16 May 2023, at 06:46, Matthew Petach  wrote:
>> > [..]
>> > I admit, I'm perhaps a little behind on the latest netflow whiz-bangs,
>> > but I've never seen a netflow record type that included HTTP cookies
>> > or PCAP data before.
>>
>> Take your pick from the "latest" ~2009 IPFIX Information Elements:
>>
>> https://www.iana.org/assignments/ipfix/ipfix.xhtml
>>
>> One can stuff almost anything in there.
>>
>> Now if one should, and if one is allowed to.
>>
>
> Wow.
>
> Thank you, Jeroen, I was indeed a bit out of date.
> Thank you for the pointer!
>
> (For those in the same boat as I, here's the relevant portion that clearly
> points out that yes, you can export the entire packet if you so desire):
>
> 313 ipHeaderPacketSection octetArray default current
>
> This Information Element carries a series of n octets from the IP header
> of a sampled packet, starting sectionOffset octets into the IP header.
>
> However, if no sectionOffset field corresponding to this Information
> Element is present, then a sectionOffset of zero applies, and the octets
> MUST be from the start of the IP header.
>
> With sufficient length, this element also reports octets from the IP
> payload. However, full packet capture of arbitrary packet streams is
> explicitly out of scope per the Security Considerations sections of [
> RFC5477 ] and [RFC2804
> ].
>
>
>
>  Thanks!
>
> Matt
> (still learning after all these years.   ^_^ )
>
>