Re: Standards Compliant Mail Client Re: V6 still not supported Re: 202203211201.AYC

[Bryan Fields]

On 3/21/22 1:57 PM, Grant Taylor via NANOG wrote:
> Glancing at the headers, it appears as if NANOG is hosted on a Mailman 
> mailing list.  As such, I believe that you could change your 
> subscription to use MIME formatted digest, which should include more 
> proper RFC-822 copies of the messages.  I believe that you could then 
> reply to these individual messages directly and match the threading that 
> I mentioned above.

I confirm this would work for the nanog list.

IMHO, digest is not the right mode to subscribe if you intend to post replies
to the list.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: Standards Compliant Mail Client Re: V6 still not supported Re: 202203211201.AYC

[William Herrin]

On Mon, Mar 21, 2022 at 9:22 AM Abraham Y. Chen  wrote:
> 1)" so it's not a chore to tell what thread you're even replying to?   ": 
>I am lost by your statement. I start each of my reply by quoting a phrase 
> or sentence of the message that I am responding to.

You've created 18 mail threads in the last 14 days and they're all
basically on the same topic. Something about your mailer or the way
you're using it has made a mess.

You're top-posting, which is against the mailing list conventions
(trim and quote inline). You're back to putting changing date stamps
in the subject lines (do you understand that email already has a date
header?) You're posting in this weird enormous html font. Basically if
you're trying to rub people the wrong way before they even read your
first word, the only thing you could do worse is capitalize every
letter.

Regards,
Bill Herrin


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

Re: V6 still not supported

[John Curran]

On 21 Mar 2022, at 12:42 PM, John Curran  wrote:
> ...
> 
> This is all quite well covered by the IPv6 recommendation document - 
> https://datatracker.ietf.org/doc/html/rfc1752 
> 
> (a document which probably should be required reading for those 
> characterizing the history of IPv6) 

Just for the record, IPv6 is definitely far from perfect…   There were things 
put in the specification that had no real world experience (some of which has 
since been deprecated), and some cases where tradeoffs were made that missed 
huge opportunities. 

However, neither the extra cruft nor the missed opportunities really got in the 
way of deployment – we are the present situation because we made a decision on 
the next IP protocol (IPv6) despite lacking the required "a straightforward 
transition plan from IPv4” – that was left as an exercise for the reader.  
Absent a clear bridge from here to there, it shouldn’t be surprising that there 
was no serious deployment for more than a decade… 

After several years of non-solutions out of the IETF, the "very large" network 
operator community (who realized that they were indeed going to need IPv6 for 
their broadband and mobile deployments) waded in and came up with workable IPv6 
transition solutions.  To this day, IPv6 remains essential to those with very 
large and growing networks, and less so for those with modest or no growth. 

FYI,
/John

Re: VPN-enabled advance fee fraud

[Mark Seiden]

of course, jay is right (in the US, anyway).

vpn providers often keep the (verified) email address and ip addresses used for 
service establishment.
expressVPN takes bitcoin and what look to me like several other anonymous 
payment schemes, and there
are always prepaid debit cards.

following the money sometimes helps.

the more general problem is that, absent a govt regulator insisting that 
EVERYBODY do this (as in China)
few service providers will want to do this voluntarily because it represents a 
cost to them which many of their 
competitors don’t have.  (registrars are another example of a service provider 
with this conundrum.)



On Mar 21, 2022, at 11:56 AM, Jay Hennigan  wrote:
> 
> On 3/21/22 11:00, Grant Taylor via NANOG wrote:
> ded.
>> What will ExpressVPN do regarding /established/ connections?  I would expect 
>> that network flows / netstat / etc. could provide some information for 
>> current, established, and ongoing.
> 
> If their intent is not to have data available for analysis, and it sure 
> sounds like it is, they aren't going to log flows or netstat. Data will be in 
> RAM during the TCP session, then poof.
> 
> -- 
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV

Re: Making Use of 240/4 NetBlock Re: 202203210957.AYC

[Abraham Y. Chen]

Dear John:

1)    "  ... everyone, said it's a foolish idea ... ":     Oh, 
"everyone", really? Are you sure? Please name a couple who expressed 
their judgments based on */facts/*. Otherwise, you may be fooling 
everyone with rumors to perpetuate a myth.


2)    By the way, through constructive criticism, we learned to 
characterize our EzIP as an */overlay/* network. With this very concise 
definition, EzIP is now ready to face real bullets. You may want to 
follow discussions about our work more closely.




Regards,

Abe (2022-03-21 15:36)




--
NANOG Digest, Vol 170, Issue 23
Message: 5
Date: 20 Mar 2022 13:58:18 -0400
From: "John Levine"
To:nanog@nanog.org
Cc:ayc...@avinta.com
Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC
Message-ID:<20220320175819.7c27c3976...@ary.qy>
Content-Type: text/plain; charset=utf-8

It appears that Abraham Y. Chen  said:


??? C.??? Recently, we were made aware of the Int-Area activities.
Attempts to reach the Group Chairs have not received any responses.

??? D.??? I just received an Int-Area Digest Vol 199, Issue 14
requesting IETF to reactivate the IPv4 support.


For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John


--


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: VPN-enabled advance fee fraud

[Grant Taylor via NANOG]

On 3/21/22 12:56 PM, Jay Hennigan wrote:
If their intent is not to have data available for analysis, and it sure 
sounds like it is, they aren't going to log flows or netstat. Data will 
be in RAM during the TCP session, then poof.


I largely agree regarding persistent storage.

However, that doesn't preclude netstat / ss / tcpdump and the likes.

There has to be /something/ correlating incoming and outgoing /active/ / 
/ongoing/ connections.


I don't see anything speaking to that real-time data in their comments 
about architecture.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Making Use of 240/4 NetBlock Re: 202203210955.AYC

[Abraham Y. Chen]

Hi, Randy:

Great analogy.


Regards,


Abe (2022-03-21 15:30)


--
NANOG Digest, Vol 170, Issue 23
Message: 12
Date: Mon, 21 Mar 2022 03:08:55 -0700
From: Randy Bush
To: Joe Maimon
Cc: North American Network Operators' Group
Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC
Message-ID:
Content-Type: text/plain; charset=US-ASCII


Is this is how the IETF ivory tower residents likes to try and
suppress debate


the ietf is an echo chamber; and if you are not in it, you do not
count.

https://archive.psg.com/051000.sigcomm-ivtf.pdf

randy


End of NANOG Digest, Vol 170, Issue 23
**


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: V6 still not supported

[Bjørn Mork]

Owen DeLong via NANOG  writes:

> Virtually every useful flow of packets in one direction requires a
> relatively symmetrical flow of packets in the other direction.

Packet captures are useful without anything being returned. It's not
uncommon to use some sort of unidirectional tunnel to transport captures
over an IP-network.

Same goes for logging. Traditional udp syslog is a one-way street.

And I'm sure there are more examples.

Not that I think it matters in this discussion, which appears more
circular than bidirectional.


Bjørn

Re: V6 still not supported

[John Curran]

On 20 Mar 2022, at 5:09 AM, Masataka Ohta  
wrote:
> 
> However, as William Allen Simpson wrote:
> 
>> Then, the powers that be declared that IPv6 should have 128-bit
>> addresses, and a host of committees were setup with competing CLNP
>> (TUBA) co-chairs. They incorporated many ideas of CLNP and XNS that
>> were thought (by many of us) to be worthless, useless, and harmful.
>> Committee-itis at its worst.
> 
> IAB hideously striked back to make IPv6 something a lot worse than
> CLNP and XNS.


Alas, the above characterization doesn’t even come close to the actual history 
of IPng – 

 - There was an open call for proposals. 
 - We had many submissions: Nimrod, PIP, SIP, TUBA, IPAE, CATNIP (TP/IX), ...
 - SIP absorbed IPAE, and then PIP merged with SIP to form SIPP
 - Three final proposals CATNIP, TUBA, SIPP
 - Chicago Big-10 workshop did final review and recommended SIPP, only using 
128-bit “NSAP-like” addresses 

This is all quite well covered by the IPv6 recommendation document - 
https://datatracker.ietf.org/doc/html/rfc1752 

(a document which probably should be required reading for those characterizing 
the history of IPv6) 

FYI,
/John

Re: VPN-enabled advance fee fraud

[Jay Hennigan]

On 3/21/22 11:00, Grant Taylor via NANOG wrote:
ded.


What will ExpressVPN do regarding /established/ connections?  I would 
expect that network flows / netstat / etc. could provide some 
information for current, established, and ongoing.


If their intent is not to have data available for analysis, and it sure 
sounds like it is, they aren't going to log flows or netstat. Data will 
be in RAM during the TCP session, then poof.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: V6 still not supported

[Owen DeLong via NANOG]

At the IP level, packets are stateless. This means that there is no such thing 
as a “unidirectional” flow of packets.

Virtually every useful flow of packets in one direction requires a relatively 
symmetrical flow of packets in the other direction.

Thus, even if you can “increase the size of the source address at transition” 
in one direction, this utterly ignores the requirement that this process must 
be reversible to send replies.

Owen


> On Mar 21, 2022, at 00:45, Vasilenko Eduard via NANOG  wrote:
> 
> Hi all,
> Hierarchical addressing when the small zone has a smaller address size, but 
> the bigger zone has a bigger address size
> Does not make too much sense.
> Indeed, it is possible to increase the source address from 32bits to 
> something bigger when the packet would go out of the small zone (and decrease 
> when the packet would go in the reverse direction).
> But it is not possible to do the same for the destination address - it should 
> be long enough (more the 32bits) from the source host to point to another 
> host far away.
> 
> Hence, the assumption below is optimistic that may be smooth interoperability 
> between smaller and bigger address spaces.
> It is the same disruptive as the introduction of IPv6.
> Eduard
> -Original Message-
> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
> Behalf Of Mark Delany
> Sent: Sunday, March 20, 2022 7:25 AM
> To: nanog@nanog.org
> Subject: Re: V6 still not supported
> 
> On 19Mar22, Matt Hoppes allegedly wrote:
> 
>> So, while it's true that a 192.168.0.1 computer couldn't connect to a
>> 43.23.0.0.12.168.0.1 computer, without a software patch - that patch 
>> would be very simple and quick to deploy
> 
> Let's call this ipv4++
> 
> Question: How does 192.168.0.1 learn about 43.23.0.0.12.168.0.1? Is that a 
> DNS lookup?
> 
> How does the DNS support ipv4++ addresses? Is that some extension to the A 
> RR? It better be an extension that doesn't break packet validation rules 
> embeded in most DNS libraries and middleware. You give 'em an A RData longer 
> than 32 bits and they're going to drop it with prejudice. Perhaps you should 
> invent a new ipv4++ address RR to avoid some of these issues?
> 
> In either case, how does every program on my ipv4 computer deal with these 
> new addresses that come back from a DNS lookup? Do you intend to modify every 
> DNS library to hide these extensions from older programs? How do you do that 
> exactly? What about my home-grown DNS library? Who patches that?
> 
> Here's a code fragment from my ipv4-only web browser:
> 
>   uint32 ip
>   ip = dnslookup("www.rivervalleyinternet.net", TypeA)
>   socket = connect(ip)
> 
> What does 'ip' contain if www.rivervalleyinternet.net is ipv4++ compliant and 
> advertises 43.23.0.0.199.34.228.100? Do these magical concentrators sniff out 
> DNS queries and do some form of translation? How does that work with DoH and 
> DoT?
> 
> Or are you suggesting that www.rivervalleyinternet.net continues to advertise 
> and listen on both 43.23.0.0.199.34.228.100 *and* good ol' 199.34.228.100 
> until virtually every client and network on the planet transitions to ipv4++? 
> In short, the transition plan is to have www.rivervalleyinternet.net run 
> dual-stacked for many years to come. Yes?
> 
> Speaking of DNS lookups. If my ipv4++ DNS server is on the same LAN as my 
> laptop, how do I talk to it? You can't ARP for ipv4++ addresses, so you'll 
> have to invent a new ARP protocol type or a new LAN protocol. Is that in your 
> patch too? Make sure the patch applies to network devices running proxy ARP 
> as well, ok?
> 
> If I connect to an ipv4++ network, how do I acquire my ipv4++ address?  If 
> it's DHCP, doesn't that require an extension to the DHCP protocol to support 
> the larger ipv4++ addresses?  So DHCP protocol extensions and changes to all 
> DHCP servers and clients are part of the patch too, right? Or perhaps you 
> plan to invent a new DHCP packet which better accomodates all of the ipv4++ 
> addresses that can get returned? Still plenty of code changes.
> 
> And how do I even do DHCP? Does ipv4++ support broadcast in the same way as 
> ipv4? What of DHCP relays? They will need to be upgraded I presume.
> 
> 
> So let's say we've solved all the issues with getting on a network, talking 
> over a LAN, acquiring an ipv4++ address, finding our ipv4++ capable router 
> and resolving ipv4++ addresses. My application is ready to send an ipv4++ 
> packet to a remote destionation.
> 
> But what does an ipv4++ packet look like on the wire? Is it an ipv4 packet 
> with bigger address fields?  An ipv4 packet with an extension? Or do you 
> propose inventing a new IP type? Do these packets pass thru ipv4-only routers 
> untainted or must they be "concentrated" beforehand?  Won't all the firewalls 
> and router vendors need to change their products to allow such packets to 
> pass? Normally oddball ipv4 packets are dropped of 

Re: IPv6 "bloat"

[Owen DeLong via NANOG]

> On Mar 20, 2022, at 22:41, Masataka Ohta  
> wrote:
> 
> Michael Thomas wrote:
> 
>> So out of the current discussions a lot of people have claimed that ipv6 is 
>> bloated or suffers from second system syndrome, etc.
> 
> IPv6 optional header chain, even after it was widely recognized
> that IPv4 options are useless/harmful and were deprecated is an
> example of IPv6 bloat.
> 
> Extensive use of link multicast for nothing is another example
> of IPv6 bloat. Note that IPv4 works without any multicast.

Yes, but IPv6 works without any broadcast. At the time IPv6 was being 
developed, broadcasts were rather inconvenient and it was believed that 
ethernet switches (which were just beginning to be a thing then) would 
facilitate more efficient capabilities by making extensive use of link 
multicast instead of broadcast.

Guess what, we are again bad at predicting the future. You have no choice when 
developing something but to make the best guess about what will happen from the 
information available at the time. Turns out multicast was arguably a wrong 
guess, but all indications available at the time were that it was a good bet.

There is still a valid argument to be made that in a switched ethernet world, 
multicast could offer efficiencies if networks were better tuned to accommodate 
it vs. broadcast. That’d be IPv4 unfriendly, but in a world where IPv4 is 
eventually deprecated and broadcasts are no longer necessary, the potential is 
there.

> 
>> So I decided to look at a linux kernel (HEAD I assume) and look at the 
>> differences between the v6 and v4 directories.
> 
> See above. That is an improper way to evaluate IPv6 bloat.
> 
> An example of second system syndrome of over-engineering
> without bloat is various timing parameters specified
> for ND, even though timing requirements are different
> depending on link types, which means there can be no
> standard timing parameters applicable to all the link
> types.
> 
> Another example of over-engineering is SLAAC to
> *statefully* maintain address configuration state
> in fully distributed way only to promote
> inconsistencies requiring DAD.

SLAAC doesn’t “statefully” maintain address state in the network or in remote 
systems. Obviously some level of statefulness is required on each local host or 
it would need to repeat the address acquisition process for each unconnected 
frame (whether initiating a connected session or a connectionless frame). DAD 
is there to avoid inconsistencies and more gracefully handle situations where 
addresses get duplicated. IPv4 is particularly bad at this and the “over 
engineering” you speak of here was seen as a solution to that problem in IPv4.

> An example of under-engineering is lack of the
> following consideration of rfc791:
> 
>The number 576 is selected to allow a reasonable sized data block to
>be transmitted in addition to the required header information.  For
>example, this size allows a data block of 512 octets plus 64 header
>octets to fit in a datagram.  The maximal internet header is 60
>octets, and a typical internet header is 20 octets, allowing a
>margin for headers of higher level protocols.
> 
> as IPv6 optional headers can be arbitrary lengthy, it is not
> guaranteed that 512B DNS message can be sent over UDP over
> IPv6.

It is guaranteed that a 512 octet DNS message can be sent over UDP if it does 
not contain extension headers. You can argue that extension headers should have 
been more carefully considered in RFC791, but two factors come into play there:

1.  I’m not sure the idea of extension headers had been fleshed out 
by the time RFC791 was written. It is one
of the earliest IPv6 RFCs.

2.  Even with full consideration of IPv6 extension headers, I think 
576 is still a reasonable MINIMUM MTU,
since a minimum MTU that can account for all extension headers 
would exceed the common 1500 octet
MTU prevalent at the time (and still relatively prevalent 
today). It’s clear from the text of RFC791 that
this number is by definition a compromise between competing 
factors, wherein there is on one side
the desire to keep the minimum MTU as small as possible and on 
the other side, the need for the
minimum MTU to accommodate a reasonable size payload under the 
majority of circumstances.
For better or worse, I think that 576 is probably as good a 
compromise as can be reached.

So I disagree with your characterization of this as under-engineered.

Owen

Re: VPN-enabled advance fee fraud

[Grant Taylor via NANOG]

On 3/21/22 11:30 AM, TJ Trout wrote:
We have carefully engineered our apps and VPN servers to categorically 
eliminate sensitive information. As a result, ExpressVPN can never be 
compelled to provide customer data that does not exist.


I understand and appreciate your architecture.

However, there seems to be one piece of information that you neglected / 
elided.


What will ExpressVPN do regarding /established/ connections?  I would 
expect that network flows / netstat / etc. could provide some 
information for current, established, and ongoing.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: VPN-enabled advance fee fraud

[Matthew Kaufman]

On Mon, Mar 21, 2022 at 10:33 AM TJ Trout  wrote:

> ExpressVPN does NOT and WILL NEVER log:
> IP addresses (source or VPN)
>
> Browsing history
>
> Traffic destination or metadata
>
> DNS queries
>
> We have carefully engineered our apps and VPN servers to categorically
> eliminate sensitive information. As a result, ExpressVPN can never be
> compelled to provide customer data that does not exist.
>

...until the NSL arrives.

Matthew Kaufman

Re: Standards Compliant Mail Client Re: V6 still not supported Re: 202203211201.AYC

[Grant Taylor via NANOG]

On 3/21/22 10:21 AM, Abraham Y. Chen wrote:
1)    " so it's not a chore to tell what thread you're even replying 
to?   ":    I am lost by your statement.


Abe, all of your replies that I've seen in the past few days have been 
brand new threads (or possibly replies to yourself).


None of your replies have been properly threaded by my email client. 
This is in contrast to almost all of the other messages that I see on 
the NANOG mailing list, which do thread properly.


I start each of my reply by quoting a phrase or sentence of the message 
that I am responding to. To be sure the original message in included, 
I copy the last message following what I am writing. I also prefix 
it with the forum message tag such as in this case "NANOG Digest, 
Vol 170, Issue 20 Message: 33 ".


I'm now speculating that you are subscribed to the "digest" version of 
the mailing list instead of receiving individual messages.


Glancing at the headers, it appears as if NANOG is hosted on a Mailman 
mailing list.  As such, I believe that you could change your 
subscription to use MIME formatted digest, which should include more 
proper RFC-822 copies of the messages.  I believe that you could then 
reply to these individual messages directly and match the threading that 
I mentioned above.


The problem with digests is that they are brand new messages / threads. 
So replies to message text therein replies to a message that most of us 
don't receive (the digest message).


This should be enough for anyone to follow in the latest exchange, 
as well as tracing it back in history from the NANOG Digest, if 
interested.  Anything more could I do to ease your efforts without 
beginning to create a long tail to a thread?


Prior to the message that I'm replying to, I was not aware that you were 
replying to the digest.


Those of us that receive individual messages as opposed to the digest 
don't have any visibility into the digest volume number, issue number, 
nor message number.  For all intents and purposes it might as well be 
the "the 4th message that passed my spam filter after my last payday".


As for the copy of the message that you're including, I wasn't aware you 
were even doing that because you appear to be top posting and I wasn't 
seeing anything below your signature.


I'd encourage you to look at the MIME formatted digest where you can 
reply to copies of the original messages and maintain threading.  Also, 
please consider not top posting.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: VPN-enabled advance fee fraud

[Josh Luthman]

What if they're actively connected and you get a subpoena?

On Mon, Mar 21, 2022 at 1:30 PM TJ Trout  wrote:

> ExpressVPN does NOT and WILL NEVER log:
> IP addresses (source or VPN)
>
> Browsing history
>
> Traffic destination or metadata
>
> DNS queries
>
> We have carefully engineered our apps and VPN servers to categorically
> eliminate sensitive information. As a result, ExpressVPN can never be
> compelled to provide customer data that does not exist.
>
> On Mon, Mar 21, 2022, 7:11 AM Andrew G. Watters 
> wrote:
>
>> Nutshell version: a group of criminals who appear to be in Mexico have
>> created an entire fake law firm and deal flow in the U.S., with
>> Photoshopped notary seals and wire instructions.  They reportedly use
>> ExpressVPN-- the owner of the IP block used by the suspects states that
>> it leased the IP block to ExpressVPN under a Letter of Authorization.
>>
>> The suspects make money by causing victims to wire advance fees to
>> Mexico as part of selling their timeshares, and possibly other
>> transactions.  My client has lost $70k or so thus far.  He has received
>> legit-looking documents, but upon even a cursory electronic inspection
>> they are obvious forgeries.  So this gang is savvy enough to steal
>> money, but really reckless as well, which may explain why they are
>> risking clicking on my links as well.  I spoke with the lawyer who they
>> are impersonating, and it was news to him that he is in New York City
>> running a law firm considering that he retired in another state many
>> years ago.
>>
>> So the suspects are offshore and I'm not sure what I can do.  But I
>> would still rather have their IP addresses than nothing.  Can I have a
>> recommendation on the best way to pursue user data from VPN providers
>> such as ExpressVPN?  I already sent in a notice to preserve logs for the
>> involved ASN, and I'm headed to Federal court in the next few days to
>> see if I have a chance to get even some of the victim's money back-- or
>> at least an injunction shutting down the suspects' online presence.  Any
>> tips on getting VPN user data (or best practices in this type of
>> situation) would be greatly appreciated.
>>
>> Best,
>>
>> Andrew Watters
>>
>> --
>> Andrew G. Watters
>> Rællic Systems
>> and...@raellic.com
>> +1 (415) 261-8527
>> https://www.raellic.com
>>
>

Re: VPN-enabled advance fee fraud

[TJ Trout]

ExpressVPN does NOT and WILL NEVER log:
IP addresses (source or VPN)

Browsing history

Traffic destination or metadata

DNS queries

We have carefully engineered our apps and VPN servers to categorically
eliminate sensitive information. As a result, ExpressVPN can never be
compelled to provide customer data that does not exist.

On Mon, Mar 21, 2022, 7:11 AM Andrew G. Watters  wrote:

> Nutshell version: a group of criminals who appear to be in Mexico have
> created an entire fake law firm and deal flow in the U.S., with
> Photoshopped notary seals and wire instructions.  They reportedly use
> ExpressVPN-- the owner of the IP block used by the suspects states that
> it leased the IP block to ExpressVPN under a Letter of Authorization.
>
> The suspects make money by causing victims to wire advance fees to
> Mexico as part of selling their timeshares, and possibly other
> transactions.  My client has lost $70k or so thus far.  He has received
> legit-looking documents, but upon even a cursory electronic inspection
> they are obvious forgeries.  So this gang is savvy enough to steal
> money, but really reckless as well, which may explain why they are
> risking clicking on my links as well.  I spoke with the lawyer who they
> are impersonating, and it was news to him that he is in New York City
> running a law firm considering that he retired in another state many
> years ago.
>
> So the suspects are offshore and I'm not sure what I can do.  But I
> would still rather have their IP addresses than nothing.  Can I have a
> recommendation on the best way to pursue user data from VPN providers
> such as ExpressVPN?  I already sent in a notice to preserve logs for the
> involved ASN, and I'm headed to Federal court in the next few days to
> see if I have a chance to get even some of the victim's money back-- or
> at least an injunction shutting down the suspects' online presence.  Any
> tips on getting VPN user data (or best practices in this type of
> situation) would be greatly appreciated.
>
> Best,
>
> Andrew Watters
>
> --
> Andrew G. Watters
> Rællic Systems
> and...@raellic.com
> +1 (415) 261-8527
> https://www.raellic.com
>

Re: VPN-enabled advance fee fraud

[Jay Hennigan]

On 3/19/22 21:23, Andrew G. Watters wrote:
Nutshell version: a group of criminals who appear to be in Mexico have 
created an entire fake law firm and deal flow in the U.S., with 
Photoshopped notary seals and wire instructions.  They reportedly use 
ExpressVPN-- the owner of the IP block used by the suspects states that 
it leased the IP block to ExpressVPN under a Letter of Authorization.


The suspects make money by causing victims to wire advance fees to 
Mexico as part of selling their timeshares, and possibly other 
transactions.  My client has lost $70k or so thus far. 


At $70K losses I'd recommend getting law enforcement involved rather 
than trying to solve this DIY. There are likely other victims.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Making Use of 240/4 NetBlock Re: 202203210953.AYC

[Abraham Y. Chen]

Hi, Joe:

1)    "... how the IETF ivory tower residents likes to try and suppress 
debate, ...  ":   Interesting metaphor. Along this line, I wonder 
whether those bouncers on the draw bridge realize that technology has 
advanced to the point that there are other ways to get around the road 
block, such as taking over the country side to leave the ivory tower in 
isolation, or parachuting to bypass the draw bridge?



Regards,


Abe (2022-03-21 12:34)



--
NANOG Digest, Vol 170, Issue 23
Message: 11
Date: Mon, 21 Mar 2022 05:31:50 -0400
From: Joe Maimon
To: John Levine,nanog@nanog.org
Cc:ayc...@avinta.com
Subject: Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC
Message-ID:<62384606.2030...@jmaimon.com>
Content-Type: text/plain; charset=UTF-8; format=flowed



John Levine wrote:


It appears that Abraham Y. Chen  said:

  C.Recently, we were made aware of the Int-Area activities.
Attempts to reach the Group Chairs have not received any responses.

  D.I just received an Int-Area Digest Vol 199, Issue 14
requesting IETF to reactivate the IPv4 support.

For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John


*ahem*
Is this is how the IETF ivory tower residents likes to try and suppress
debate, by relegating all group think dissenters as white noise
nobodies? And if they have succeeded in doing such on their own forums,
its more telling about their own process problems than anything else.

I sincerely hope I am mistaken in your characterization of the many fine
individuals who have repeatedly gone on record in support of maintaining
IPv4 responsibly until such time as it is properly obsoleted.

While I can understand being considered a nobody, other more notable
definitely not nobodies have even on this tired topics' nth thread made
themselves heard and some fairly clearly.

History will continue to show that the IETF pursued the path of pain for
the internet.

Joe




--


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Standards Compliant Mail Client Re: V6 still not supported Re: 202203211201.AYC

[Abraham Y. Chen]

Hi, Blake:

1)    " so it's not a chore to tell what thread you're even replying 
to?   ":    I am lost by your statement. I start each of my reply by 
quoting a phrase or sentence of the message that I am responding to. To 
be sure the original message in included, I copy the last message 
following what I am writing. I also prefix it with the forum message tag 
such as in this case "NANOG Digest, Vol 170, Issue 20 Message: 33 ". 
This should be enough for anyone to follow in the latest exchange, as 
well as tracing it back in history from the NANOG Digest, if interested. 
Anything more could I do to ease your efforts without beginning to 
create a long tail to a thread?


2)    " ... a standards compliant mail client ...   ":    Please name 
the "standards" and list a couple software that comply with it. This is 
a topic that I am actually very interested in studying because eMails 
these days come in too many formats / styles. Please teach me.


Thanks,


Abe (2022-03-21 12:20)



On 2022-03-20 19:01, Blake Dunlap wrote:
Can you get a standards compliant mail client so it's not a chore to 
tell what thread you're even replying to?


On Fri, Mar 18, 2022, 11:44 Abraham Y. Chen  wrote:

Dear Borg:

1)    " ... I dont see a way of extending IPv4 without making it a
new protocol.  ... new IP protocol that is much more similar to
IPv4, just extends address space. ... ":    I believe that you
will be pleasantly surprised at the proposal summarized by the the
below whitepaper. It proposes an overlay architecture over the
current Internet. As such, assignable IPv4 addresses are extended
without the baggage of the current Internet and no new protocol.
To begin the deployment, all need be done is "*/disabling/* the
program code that has been */disabling/* the use of the 240/4
netblock" in routers.

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

2)    The "transition" will be mostly transparent from ordinary
users' point of view, because IoTs do not need be reprogrammed.
Please feel free to ask me to describe specific issues that you
may come across.

Regards,


Abe (2022-03-18 12:43)



--
NANOG Digest, Vol 170, Issue 20

Message: 33
Date: Fri, 18 Mar 2022 09:36:40 +0100 (CET)
From:b...@uu3.net
To:nanog@nanog.org
Subject: Re: V6 still not supported
Message-ID: 
Content-Type: TEXT/PLAIN; charset=US-ASCII

While Im dont like IPv6, I see it as a bad idea.
>From my knowledge I dont see a way of extending IPv4 without making it
a new protocol. It was not designed that way.

What I would LOVE to see that someone will pop in with new IP protocol
that is much more similar to IPv4, just extends address space and fixes
some well know issues. (for example remove netmask and use prefixlen/CIDR).

Other importand aspect is some kind of IPvX -> IPv4 interop, so you can
quickly put clients into new protocol and they have access to entire IPv4
internet out of the box.

Also, we need to please enterprises so we need largish RFC1918 space too.

Just my 2 cents again


-- Original message --

From: Matt Hoppes  

To: Joe Maimon  
,b...@theworld.com,
 Tom Beecher  
Cc: NANOG  
Subject: Re: V6 still not supported
Date: Thu, 17 Mar 2022 23:34:19 -0500

At this point I would**love**  to see IPv4 get extended, a software patch 
applied
to devices, and IPv6 die a quick painless death.


Its not impossible to envision that IPv4 does not ever go away but actually
gets extended in such a way that it obsoletes IPv6. The longer this drags 
out
the less implausible it seems.

Joe






Virus-free. www.avast.com




<#m_-5998402233395781358_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

A quick note of appreciation

[Etienne-Victor Depasquale via NANOG]

I've occasionally posted to this list,
but mostly take a seat in the audience.

*** And what a show this is! ***
First-class technical discussions, updated news, timely responses.

God bless NANOG,
and may this community keep up its invaluable contribution to networking,
and thereby, to all of society.

With humble gratitude,

Etienne

-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Survey on DNS resolver operations and DNSSEC

[Moritz Müller via NANOG]

Hi everyone,

The DNS Security Extensions (DNSSEC) add integrity and authenticity to the
Domain Name System (DNS). Now, more than 17 years after their
standardization, we would like to hear from DNS recursive resolver operators
about their experience with DNSSEC. For this reason, we have set up a short
survey. It’s directed mainly towards organisations that run a recursive
resolver. Filling out the survey should take roughly 5 to 10 minutes.

https://forms.gle/FxTD9FofaogdvLqcA (link directs to Google Forms)

This survey is carried out by SIDN Labs (https://sidnlabs.nl) and by the
Swedish Internet Foundation (https://internetstiftelsen.se/en/). You can
contact us via email: moritz.mul...@sidn.nl

Please excuse us, if you have received this email via different mailing
lists.

—
Moritz Müller Research Engineer at SIDN Labs


signature.asc
Description: Message signed with OpenPGP

RE: V6 still not supported

[Vasilenko Eduard via NANOG]

Hi all,
Hierarchical addressing when the small zone has a smaller address size, but the 
bigger zone has a bigger address size
Does not make too much sense.
Indeed, it is possible to increase the source address from 32bits to something 
bigger when the packet would go out of the small zone (and decrease when the 
packet would go in the reverse direction).
But it is not possible to do the same for the destination address - it should 
be long enough (more the 32bits) from the source host to point to another host 
far away.

Hence, the assumption below is optimistic that may be smooth interoperability 
between smaller and bigger address spaces.
It is the same disruptive as the introduction of IPv6.
Eduard
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Mark Delany
Sent: Sunday, March 20, 2022 7:25 AM
To: nanog@nanog.org
Subject: Re: V6 still not supported

On 19Mar22, Matt Hoppes allegedly wrote:

> So, while it's true that a 192.168.0.1 computer couldn't connect to a
> 43.23.0.0.12.168.0.1 computer, without a software patch - that patch 
> would be very simple and quick to deploy

Let's call this ipv4++

Question: How does 192.168.0.1 learn about 43.23.0.0.12.168.0.1? Is that a DNS 
lookup?

How does the DNS support ipv4++ addresses? Is that some extension to the A RR? 
It better be an extension that doesn't break packet validation rules embeded in 
most DNS libraries and middleware. You give 'em an A RData longer than 32 bits 
and they're going to drop it with prejudice. Perhaps you should invent a new 
ipv4++ address RR to avoid some of these issues?

In either case, how does every program on my ipv4 computer deal with these new 
addresses that come back from a DNS lookup? Do you intend to modify every DNS 
library to hide these extensions from older programs? How do you do that 
exactly? What about my home-grown DNS library? Who patches that?

Here's a code fragment from my ipv4-only web browser:

   uint32 ip
   ip = dnslookup("www.rivervalleyinternet.net", TypeA)
   socket = connect(ip)

What does 'ip' contain if www.rivervalleyinternet.net is ipv4++ compliant and 
advertises 43.23.0.0.199.34.228.100? Do these magical concentrators sniff out 
DNS queries and do some form of translation? How does that work with DoH and 
DoT?

Or are you suggesting that www.rivervalleyinternet.net continues to advertise 
and listen on both 43.23.0.0.199.34.228.100 *and* good ol' 199.34.228.100 until 
virtually every client and network on the planet transitions to ipv4++? In 
short, the transition plan is to have www.rivervalleyinternet.net run 
dual-stacked for many years to come. Yes?

Speaking of DNS lookups. If my ipv4++ DNS server is on the same LAN as my 
laptop, how do I talk to it? You can't ARP for ipv4++ addresses, so you'll have 
to invent a new ARP protocol type or a new LAN protocol. Is that in your patch 
too? Make sure the patch applies to network devices running proxy ARP as well, 
ok?

If I connect to an ipv4++ network, how do I acquire my ipv4++ address?  If it's 
DHCP, doesn't that require an extension to the DHCP protocol to support the 
larger ipv4++ addresses?  So DHCP protocol extensions and changes to all DHCP 
servers and clients are part of the patch too, right? Or perhaps you plan to 
invent a new DHCP packet which better accomodates all of the ipv4++ addresses 
that can get returned? Still plenty of code changes.

And how do I even do DHCP? Does ipv4++ support broadcast in the same way as 
ipv4? What of DHCP relays? They will need to be upgraded I presume.


So let's say we've solved all the issues with getting on a network, talking 
over a LAN, acquiring an ipv4++ address, finding our ipv4++ capable router and 
resolving ipv4++ addresses. My application is ready to send an ipv4++ packet to 
a remote destionation.

But what does an ipv4++ packet look like on the wire? Is it an ipv4 packet with 
bigger address fields?  An ipv4 packet with an extension? Or do you propose 
inventing a new IP type? Do these packets pass thru ipv4-only routers untainted 
or must they be "concentrated" beforehand?  Won't all the firewalls and router 
vendors need to change their products to allow such packets to pass? Normally 
oddball ipv4 packets are dropped of course. As we know, vendor changes can 
notoriously take decades; just ask the ipv6 crowd.

Ok. We've upgraded all our infrastructure to route ipv4++ packets. The packet 
reached the edge of our network. But how does the edge know that the next hop 
(our ISP) supports
ipv4++ packets?  Do routers have to exchange capabilities with each 
ipv4++ other? How do they do
that?

For that matter, how does my application know that the whole path thru to the 
destination supports ipv4++? It only needs one transition across an ipv4-only 
network somewhere in the path and the packet will be dropped. I think you're 
going to have to advertise ipv4++ reachability on a per-network basis. Perhaps 

VPN-enabled advance fee fraud

[Andrew G. Watters]

Nutshell version: a group of criminals who appear to be in Mexico have 
created an entire fake law firm and deal flow in the U.S., with 
Photoshopped notary seals and wire instructions.  They reportedly use 
ExpressVPN-- the owner of the IP block used by the suspects states that 
it leased the IP block to ExpressVPN under a Letter of Authorization.


The suspects make money by causing victims to wire advance fees to 
Mexico as part of selling their timeshares, and possibly other 
transactions.  My client has lost $70k or so thus far.  He has received 
legit-looking documents, but upon even a cursory electronic inspection 
they are obvious forgeries.  So this gang is savvy enough to steal 
money, but really reckless as well, which may explain why they are 
risking clicking on my links as well.  I spoke with the lawyer who they 
are impersonating, and it was news to him that he is in New York City 
running a law firm considering that he retired in another state many 
years ago.


So the suspects are offshore and I'm not sure what I can do.  But I 
would still rather have their IP addresses than nothing.  Can I have a 
recommendation on the best way to pursue user data from VPN providers 
such as ExpressVPN?  I already sent in a notice to preserve logs for the 
involved ASN, and I'm headed to Federal court in the next few days to 
see if I have a chance to get even some of the victim's money back-- or 
at least an injunction shutting down the suspects' online presence.  Any 
tips on getting VPN user data (or best practices in this type of 
situation) would be greatly appreciated.


Best,

Andrew Watters

--
Andrew G. Watters
Rællic Systems
and...@raellic.com
+1 (415) 261-8527
https://www.raellic.com

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Randy Bush]

> Is this is how the IETF ivory tower residents likes to try and
> suppress debate

the ietf is an echo chamber; and if you are not in it, you do not
count.

https://archive.psg.com/051000.sigcomm-ivtf.pdf

randy

Re: Making Use of 240/4 NetBlock Re: 202203151549.AYC

[Joe Maimon]

John Levine wrote:

It appears that Abraham Y. Chen  said:

 C.Recently, we were made aware of the Int-Area activities.
Attempts to reach the Group Chairs have not received any responses.

 D.I just received an Int-Area Digest Vol 199, Issue 14
requesting IETF to reactivate the IPv4 support.

For people who don't follow the IETF lists, here's a summary of
the responses.  Mr. Chen thought it was a good idea, everyone
else, and I mean everyone, said it's a foolish idea and not
worth pursuing.

R's,
John


*ahem*
Is this is how the IETF ivory tower residents likes to try and suppress 
debate, by relegating all group think dissenters as white noise 
nobodies? And if they have succeeded in doing such on their own forums, 
its more telling about their own process problems than anything else.


I sincerely hope I am mistaken in your characterization of the many fine 
individuals who have repeatedly gone on record in support of maintaining 
IPv4 responsibly until such time as it is properly obsoleted.


While I can understand being considered a nobody, other more notable 
definitely not nobodies have even on this tired topics' nth thread made 
themselves heard and some fairly clearly.


History will continue to show that the IETF pursued the path of pain for 
the internet.


Joe