Re: v6 DNSSEC fail, was Buying IPv4 blocks

[Brandon Martin]

On 10/5/18 1:53 AM, Mark Andrews wrote:

If you don’t want fragmented IPv6 UDP responses use

server ::/0 { edns-udp-size 1232; };

That’s 1280 - IPv6 header - UDP header.  Anything bigger than that can 
theoretically
be fragmented.  You will then have to deal with PMTUD failures as the servers 
switch
over to TCP.


Speaking of, anyone have any good reports similar to that which was the 
genesis of this discussion but regarding PMTUD broken-ness on IPv6? 
Perhaps specifically focusing on its impact w.r.t DNS over TCP?


My understanding is that this is quite common on IPv4 but not as evident 
due to in-transit transparent fragmentation.




What I find ridiculous is firewall vendor that claim to support adding stateful 
rules
on demand but don’t add “from  to  frag offset != 0” when they add “from  to 
 proto xxx src-port  dst-port ” or don’t do packet reassembly to
work around the lack of passing fragments.  This is IP and fragments are part
and parcel of IP whether it is IPv4 or IPv6.


I think the "justification" for not allowing fragments is that they can 
be crafted specifically to evade filter policies.


Now, I'd argue that, if you want to not be a broken device, you then 
need to do reassembly so that you can inspect.  At minimum, do so for 
the typical attack case which uses very small fragments and/or large L3 
headers to split up application data since the result is presumably 
something that fits within the MTU of your LAN.  Or statefully track 
whether fragments are expected for a conversation.  Or drop fragments 
that could be used to evade policies but permit fragments that couldn't. 
 Or...something other than breaking things horribly and whining that 
the protocol is broken.


Of course, a lot of these are also the same boxes that, through design 
or misconfiguration, break PMTUD, too, I suspect.

--
Brandon Martin

Re: v6 DNSSEC fail, was Buying IPv4 blocks

[Mark Andrews]

> On 5 Oct 2018, at 3:12 pm, Mark Tinka  wrote:
> 
> 
> 
> On 5/Oct/18 03:07, John Levine wrote:
> 
>> Yeah, V6 UDP fragmentation and anycast are bad news.  You can sort of
>> fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot
>> easier to stick to v4.
>> 
>> Geoff Huston has written about this a lot and it's a well known problem
>> in the DNS community.  I'm surprised if it's news to anyone here.
>> 
>> 
>> https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/
> 
> In BIND, I think this can be solved by using the "minimal-responses" knob.
> 
> Mark.

If you don’t want fragmented IPv6 UDP responses use

server ::/0 { edns-udp-size 1232; };

That’s 1280 - IPv6 header - UDP header.  Anything bigger than that can 
theoretically
be fragmented.  You will then have to deal with PMTUD failures as the servers 
switch
over to TCP.

What I find ridiculous is firewall vendor that claim to support adding stateful 
rules
on demand but don’t add “from  to  frag offset != 0” when they add 
“from  to  proto xxx src-port  dst-port ” or 
don’t do packet reassembly to
work around the lack of passing fragments.  This is IP and fragments are part
and parcel of IP whether it is IPv4 or IPv6.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: v6 DNSSEC fail, was Buying IPv4 blocks

[Mark Tinka]

On 5/Oct/18 03:07, John Levine wrote:

> Yeah, V6 UDP fragmentation and anycast are bad news.  You can sort of
> fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot
> easier to stick to v4.
>
> Geoff Huston has written about this a lot and it's a well known problem
> in the DNS community.  I'm surprised if it's news to anyone here.
>
> https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/

In BIND, I think this can be solved by using the "minimal-responses" knob.

Mark.

Re: Oct. 3, 2018 EAS Presidential Alert test

[bzs]

Just to try to squeeze something worthwhile out of these reports...

I wonder, if there were a real alert, what the odds are that one
wouldn't hear about it in 1 minute, 5 minutes, etc even if they didn't
personally get it.

Obviously edge cases are possible, you were deep in a cave with your
soccer team, but there must be mathematical modeling of that sort of
information dispersion.

It would have to account for other possible channels, word of mouth,
facebook, twitter, &c posts or really any informatonal source you were
on on the internet (e.g., news sites), TV, radio, people screaming in
the streets, etc.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: bloomberg on supermicro: sky is falling

[Jason Hellenthal]

You are what you allow

-- 

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 4, 2018, at 17:07, Naslund, Steve  wrote:
> 
> It would be really noticeable.  In the secure networks I have worked with 
> "default routes" were actually strictly forbidden.  Also, ACLs and firewall 
> policy is all written with Deny All policy first.  Everything talking through 
> them is explicitly allowed.
> 
> The government especially in the three letter intel agencies is not a 
> clownish as they are depicted.
> 
> Steven Naslund
> Chicago IL
> 
>> Which makes the traffic that wanders towards the default route where
>> nothing should go *very* noticeable.
>> 
>> Regards,
>> Bill Herrin
> 

Re: v6 DNSSEC fail, was Buying IPv4 blocks

[John Levine]

In article <60afb948-5f6d-8ea8-00c9-6d4d92ff0...@forfun.net>,
Marco Davids via NANOG  wrote:
>> Even if you do have v6, some things like DNSSEC don't work very well
>> if you can't do them over v4.
>
>Is that so?

Yeah, V6 UDP fragmentation and anycast are bad news.  You can sort of
fix it by doing all your v6 DNSSEC DNS queries over TCP but it's a lot
easier to stick to v4.

Geoff Huston has written about this a lot and it's a well known problem
in the DNS community.  I'm surprised if it's news to anyone here.

https://blog.apnic.net/2017/08/22/dealing-ipv6-fragmentation-dns/

Re: bloomberg on supermicro: sky is falling

[Scott Weeks]

--- eric.kuh...@gmail.com wrote:
From: Eric Kuhnke 

 many contractors *do* have sensitive data on their 
networks with a gateway out to the public Internet. 


I could definitely imagine that happening.

scott

Re: bloomberg on supermicro: sky is falling

[Scott Weeks]

--- ra...@psg.com wrote:
From: Randy Bush 

> Classified networks do not connect to other networks unless
> they are equally or higher classified.

that sentence makes no sense.  if A can connect to B because B is more
highly classified than A, then B is connecting to a less classified
network A.
-


Yeah, I borked that higher thing, but I still stand by the no internet 
access.  Someone bends that rule and trouble follows.

scott

RE: bloomberg on supermicro: sky is falling

[Naslund, Steve]

It would be really noticeable.  In the secure networks I have worked with 
"default routes" were actually strictly forbidden.  Also, ACLs and firewall 
policy is all written with Deny All policy first.  Everything talking through 
them is explicitly allowed.

The government especially in the three letter intel agencies is not a clownish 
as they are depicted.

Steven Naslund
Chicago IL

>Which makes the traffic that wanders towards the default route where
>nothing should go *very* noticeable.
>
>Regards,
>Bill Herrin

Re: bloomberg on supermicro: sky is falling

[Mark Rousell]

On 04/10/2018 22:28, Naslund, Steve wrote:
>
> Quite different really.  FIREWALK is really an intercept device to get
> data out of a firewalled or air gapped network.  The exploit Bloomberg
> describes would modify or alter data going across a server’s bus.  The
> big difference is the Bloomberg device needs command and control and a
> place to dump the tapped data to over the server’s network
> connection.  That device is not going to be able to do so out of any
> classified military network I have ever worked on.  Or anyone with a
> halfway decent firewall (which I would assume Apple and Amazon would
> have for the internal servers).  I think this article is unlikely to
> be true for the following reasons :
>
>  
>
> 1.   Separate chip is much more detectable physically than an
> altered chipset that is already on the board.
>
> 2.   Requires motherboard redesign to get access to power and
> buses needed (again easily detectable during any design mods “hey does
> anyone know what these are for?”)
>
> 3.   Does not have onboard communications so it will be sending
> data traffic on the network interfaces (will definitely trigger even
> the most rudimentary IDP systems).It relies on these backbone
> Internet companies and Intelligence agencies to have absolutely
> abysmal security on their networks to be at all useful.
>
> 4.   Parts would have to be brought into the plant, stored
> somewhere, and all the internal systems would need a trail of  where
> the part came from, how ordered it, where it is warehoused, loaded
> into pick/place, etc.  Much better to compromised an existing chips
> supply chain.
>

Whatever the truth here, I'm sure that the article as it is written
isn't telling us everything. There's more to this than meets the eye
including, quite possibly, the full facts about how data would be
exfiltrated and/or, perhaps, exactly what was done to the customers'
hardware.

> Does anyone think that someone somewhere is trying to kill
> Supermicro?  They sure have had a lots of bad news lately.
>

Who knows. Perhaps we are intended to come away with certain impressions.

-- 
Mark Rousell

Re: bloomberg on supermicro: sky is falling

[William Herrin]

On Thu, Oct 4, 2018 at 5:17 PM Scott Weeks  wrote:
> --- snasl...@medline.com wrote:
>> The other thing I am highly skeptical of is the suggestion
>> of attempting to tap sensitive intel agency systems this way.
>> Talking to a C&C server is suicide from within their network.
>
> Classified networks do not connect to other networks unless
> they are equally or higher classified.  No internet connection.
> Period.

Which makes the traffic that wanders towards the default route where
nothing should go *very* noticeable.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

RE: bloomberg on supermicro: sky is falling

[Naslund, Steve]

Remember it's the data that is classified, not the network.  It does not matter 
if you have IP connectivity, it matters if the classified data is allowed to 
move over the connection. When a government agency talks about a "classified 
network" they are talking about a network that has been approved to transport 
the data and has appropriate access controls.  Just because your email server 
is attached to the Internet does not mean I have access to its data.  Same in 
the classified world, just because you can send an email from the Internet to 
SIPRNET does not mean you have SIPRNET access.

Steven Naslund
Chicago IL

>> Classified networks do not connect to other networks unless
>> they are equally or higher classified.

>that sentence makes no sense.  if A can connect to B because B is more
>highly classified than A, then B is connecting to a less classified
>network A.
>
>randy

RE: bloomberg on supermicro: sky is falling

[Naslund, Steve]

>> Classified networks do not connect to other networks unless they are 
>> equally or higher classified.  No internet connection.
>> Period.

Not quite but there are at least application level gateways.  For example, 
there are usually gateway that can let unclassified email flow into classified 
systems.  However there is an application gateway to allow ONLY email protocols 
and only in the desired direction.

>Well, if your classified network is connecting to a higher classified net, then
>*that* network is connecting to a lower classified net, right?

In a very highly controlled manner.  The lower classified network may only be 
allowed to send data to the higher classified network.  If the higher level 
network is multilevel capable it will be allowed to move documents to the lower 
level network if they are at the right level of classification.  Again this is 
application layer security and all levels below that would not be trusted 
between the two networks.  A gateway with a specialized application would have 
vetted connectivity to both networks.

>That, plus I think the Snowden escapade was ample proof that security rules 
>will get bent when needed to get work done - it turned out that Snowden was 
>able to walk off with terabytes of data because >security restrictions had 
>been disabled because they were putting a crimp in the analysts' style...

That is completely different.  We are talking HUMINT instead of ELINT or 
SIGINT.  Snowden flat out stole the data as an insider.

Steven Naslund 
Chicago IL

Re: bloomberg on supermicro: sky is falling

[Mark Rousell]

On 04/10/2018 22:00, Naslund, Steve wrote:
> The other thing I am highly skeptical of is the suggestion of attempting to 
> tap sensitive intel agency systems this way.  Talking to a C&C server is 
> suicide from within their network.  How long do you think it would take them 
> to detect a reach out to the Internet from inside?  How are you going to get 
> the data from the outside back into their network?  You still have to defeat 
> their firewalls to do it.  If this was targeted to specialized video 
> processing server then would it not be unusual for them to be talking to some 
> random IP address on the Internet?

If I understand the article correctly, all the 'infected' systems were
built for outsourced service providers so not intended directly for the
most sensitive of systems. Still, I agree that network activity is
inevitably going to be seen in any modern competent network. In fact,
the article states that odd network traffic is how Apple found out about
the implants.

I have observed that a common trait in technically complex stories like
this is that we are not seeing the whole story. Key facts that cause
everything to make sense to technical readers are often left out, either
because those who have the information cannot release it (for safety or
security reasons) or because it's perceived as too complex for the
readership to understand. Sometimes these issues even result in
deliberate inaccuracies being introduced.

To put it another way: Considering that, if true, these were carefully
targeted attacks it is possible that there were other ways to exfiltrate
the target data that have been glossed over.

That said, even in highly complex or high cost plans, people sometimes
make basic errors. Misplaced decimal places, wrong units, etc. Perhaps
relaying on network access was another basic error.

-- 
Mark Rousell

RE: bloomberg on supermicro: sky is falling

[Naslund, Steve]

Quite different really.  FIREWALK is really an intercept device to get data out 
of a firewalled or air gapped network.  The exploit Bloomberg describes would 
modify or alter data going across a server’s bus.  The big difference is the 
Bloomberg device needs command and control and a place to dump the tapped data 
to over the server’s network connection.  That device is not going to be able 
to do so out of any classified military network I have ever worked on.  Or 
anyone with a halfway decent firewall (which I would assume Apple and Amazon 
would have for the internal servers).  I think this article is unlikely to be 
true for the following reasons :


1.   Separate chip is much more detectable physically than an altered 
chipset that is already on the board.

2.   Requires motherboard redesign to get access to power and buses needed 
(again easily detectable during any design mods “hey does anyone know what 
these are for?”)

3.   Does not have onboard communications so it will be sending data 
traffic on the network interfaces (will definitely trigger even the most 
rudimentary IDP systems).It relies on these backbone Internet companies and 
Intelligence agencies to have absolutely abysmal security on their networks to 
be at all useful.

4.   Parts would have to be brought into the plant, stored somewhere, and 
all the internal systems would need a trail of  where the part came from, how 
ordered it, where it is warehoused, loaded into pick/place, etc.  Much better 
to compromised an existing chips supply chain.

Does anyone think that someone somewhere is trying to kill Supermicro?  They 
sure have had a lots of bad news lately.

Steven Naslund
Chicago IL

>To me this looks like a Chinese version of the NSA FIREWALK product. Which is 
>a network implant built into a RJ45 jack intended to be soldered onto a 
>motherboard. The FIREWALK info came out with the Snowden leaks in 2013 and the 
>tech was >years old at that time.
>
>https://en.wikipedia.org/wiki/NSA_ANT_catalog
>
>I am not able to say a lot more, but when I worked for a major defence 
>contractor in 2006-2007 in Afghanistan, building WAN links in and out of the 
>country by satellite, hardware implants were found in equipment. Not our 
>equipment, but it was close >enough to our operations that we were briefed on 
>it and made aware.

Re: bloomberg on supermicro: sky is falling

[Randy Bush]

> Classified networks do not connect to other networks unless
> they are equally or higher classified.

that sentence makes no sense.  if A can connect to B because B is more
highly classified than A, then B is connecting to a less classified
network A.

randy

Re: bloomberg on supermicro: sky is falling

[valdis . kletnieks]

On Thu, 04 Oct 2018 14:10:07 -0700, "Scott Weeks" said:

> Classified networks do not connect to other networks unless
> they are equally or higher classified.  No internet connection.
> Period.

Well, if your classified network is connecting to a higher classified net, then
*that* network is connecting to a lower classified net, right?

That, plus I think the Snowden escapade was ample proof that security rules
will get bent when needed to get work done - it turned out that Snowden was
able to walk off with terabytes of data because security restrictions had been
disabled because they were putting a crimp in the analysts' style...




pgpdUzXhK20Nn.pgp
Description: PGP signature

Re: bloomberg on supermicro: sky is falling

[Eric Kuhnke]

The US' extensive reliance on third party commercial contractors to
implement a lot of programs, means that despite laws and SOW/PWS for their
contracts, many contractors *do* have sensitive data on their networks with
a gateway out to the public Internet. I have seen it. I have cringed at it.
SIGINT agencies in many cases rely on people being less than perfectly
reliable in their data hygiene practices to extract useful information.

I'm sure that all of the super secret squirrel stuff is going on properly
inside SCIFs, but mistakes will be made. Now draw an imaginary venn diagram
overlap of human mistakes with places that handle classified data.

On Thu, Oct 4, 2018 at 2:21 PM  wrote:

> On Thu, 04 Oct 2018 21:00:57 -, "Naslund, Steve" said:
> > The other thing I am highly skeptical of is the suggestion of attempting
> to
> > tap sensitive intel agency systems this way.  Talking to a C&C server is
> > suicide from within their network.  How long do you think it would take
> them to
> > detect a reach out to the Internet from inside?
>
> Oh, at least 2 or 3 years. Or that's how long it took to be noticed the
> *last* time.
>
> https://en.wikipedia.org/wiki/Titan_Rain
>
>

Re: bloomberg on supermicro: sky is falling

[valdis . kletnieks]

On Thu, 04 Oct 2018 21:00:57 -, "Naslund, Steve" said:
> The other thing I am highly skeptical of is the suggestion of attempting to
> tap sensitive intel agency systems this way.  Talking to a C&C server is
> suicide from within their network.  How long do you think it would take them 
> to
> detect a reach out to the Internet from inside?

Oh, at least 2 or 3 years. Or that's how long it took to be noticed the *last* 
time.

https://en.wikipedia.org/wiki/Titan_Rain



pgplJW9Blew12.pgp
Description: PGP signature

RE: bloomberg on supermicro: sky is falling

[Scott Weeks]

--- snasl...@medline.com wrote:
From: "Naslund, Steve" 

The other thing I am highly skeptical of is the suggestion 
of attempting to tap sensitive intel agency systems this way.  
Talking to a C&C server is suicide from within their network.  
--


Classified networks do not connect to other networks unless
they are equally or higher classified.  No internet connection.
Period.

scott

Re: bloomberg on supermicro: sky is falling

[Randy Bush]

> To me this looks like a Chinese version of the NSA FIREWALK product.

so the good thing about the trade war with china is that it keeps
implant designers fully employed on both sides.  they can't just buy
eachother's implants; the  tariffs would be too high.

randy

RE: bloomberg on supermicro: sky is falling

[Naslund, Steve]

I can read but I am really finding it hard to believe that they all agreed to 
even comment on it at all.  Especially the PRC.  Next question would be that if 
Bloomberg was calling me for "months to a year" why not get out in front of it 
in the first place?  The whole story and its responses are very flakey at least 
to my BS detector.

Steven Naslund
Chicago IL


>As they mentioned in their responses, Bloomberg has been calling each
>of the companies for comment on the developing article for months to a
>year. That's why they all knew it was coming.
>
>Regards,
>Bill Herrin

Re: bloomberg on supermicro: sky is falling

[Eric Kuhnke]

To me this looks like a Chinese version of the NSA FIREWALK product. Which
is a network implant built into a RJ45 jack intended to be soldered onto a
motherboard. The FIREWALK info came out with the Snowden leaks in 2013 and
the tech was years old at that time.

https://en.wikipedia.org/wiki/NSA_ANT_catalog

I am not able to say a lot more, but when I worked for a major defence
contractor in 2006-2007 in Afghanistan, building WAN links in and out of
the country by satellite, hardware implants were found in equipment. Not
our equipment, but it was close enough to our operations that we were
briefed on it and made aware.



On Thu, Oct 4, 2018 at 10:02 AM Randy Bush  wrote:

> re:
> https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
>
> from a side convo with a well known sec researcher:
>
> >> saw that a couple of years back when apple tossed them out.  so who
> >> do we know that is for sure not poisoned.  and therein lies the rub.
> > Yup
>
> truth is, i am surprised they had to add a chip, and one of the larger
> dies was not already trojaned.
>
> have visions of the chinese implant on box A fighting with the american
> implant on box B with occasional jabs from the israelis from box C.
>
> what i would love to see/know is how apple tries to vet the macs made in
> shenzhen.
>
> randy
>

RE: bloomberg on supermicro: sky is falling

[Naslund, Steve]

It is definitely more desirable to try and tap a serialized data line than the 
parallel lines.  The thing that made me most suspicious of the article is why 
would anyone add a chip.  It requires power and connections that a highly 
detectable.  Motherboard designs are very complex in the characteristics of 
data buses so it is not so easy to just extend or tap into them without having 
negative effects (which brings the board under scrutiny that we don't want).  
Why not embed our rogue chip inside the case of a chip that is already 
controlling the bus or memory we want to play with?  It would be really hard to 
detect without x-ray of all of the system chipsets.

The other thing I am highly skeptical of is the suggestion of attempting to tap 
sensitive intel agency systems this way.  Talking to a C&C server is suicide 
from within their network.  How long do you think it would take them to detect 
a reach out to the Internet from inside?  How are you going to get the data 
from the outside back into their network?  You still have to defeat their 
firewalls to do it.  If this was targeted to specialized video processing 
server then would it not be unusual for them to be talking to some random IP 
address on the Internet?


Steven Naslund
Chicago IL

>Just theory - tapping on same lines as SPI flash (let's assume it is not 
>QSPI), so we are "in parallel", as "snooper" chip.
>First - it can easily snoop by listening MISO/MOSI/CS/CLK.
>When required data pattern and block detected during snooping, it can 
>remember offset(s) of required data.
>When, later, BMC send over MOSI request for this "offset", we override 
>BMC and force CS high (inactive), so main flash chip will not answer, 
>and answer instead of him our, different data from "snooper".
>Voila... instead of root:password we get root:nihao

Re: bloomberg on supermicro: sky is falling

[William Herrin]

On Thu, Oct 4, 2018 at 4:37 PM Naslund, Steve  wrote:
> On the opposite side of the argument, does anyone think it is strange that 
> all of
> the companies mentioned in the article along with the PRC managed to get a
> simultaneous response back to Bloomberg.  Seems pretty pre-calculated to
> me.  Or did some agency somewhere tell everyone they better shut up
> about the whole thing?

As they mentioned in their responses, Bloomberg has been calling each
of the companies for comment on the developing article for months to a
year. That's why they all knew it was coming.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: bloomberg on supermicro: sky is falling

[Denys Fedoryshchenko]

On 2018-10-04 23:37, Naslund, Steve wrote:

I was wondering about where this chip tapped into all of the data and
timing lines it would need to have access to.  It would seem that
being really small creates even more problems making those
connections.  I am a little doubtful about the article.  It would seem
to me better to create a corrupted copy of something like a front side
bus chipset, memory controller or some other component that handles
data lines than create a new component that would then require a
motherboard redesign to integrate correctly.  It would seem that as
soon as the motherboard design was changed someone would wonder "hey,
where are all those data lines going?"  It would also require less
people in on the plan to corrupt or replace a device already in the
design.  All you need is a way to intercept the original chip supply
and insert your rogue devices.

On the opposite side of the argument, does anyone think it is strange
that all of the companies mentioned in the article along with the PRC
managed to get a simultaneous response back to Bloomberg.  Seems
pretty pre-calculated to me.  Or did some agency somewhere tell
everyone they better shut up about the whole thing?

Steven Naslund
Chicago IL


Just theory - tapping on same lines as SPI flash (let's assume it is not 
QSPI), so we are "in parallel", as "snooper" chip.

First - it can easily snoop by listening MISO/MOSI/CS/CLK.
When required data pattern and block detected during snooping, it can 
remember offset(s) of required data.
When, later, BMC send over MOSI request for this "offset", we override 
BMC and force CS high (inactive), so main flash chip will not answer, 
and answer instead of him our, different data from "snooper".

Voila... instead of root:password we get root:nihao

RE: bloomberg on supermicro: sky is falling

[Naslund, Steve]

I was wondering about where this chip tapped into all of the data and timing 
lines it would need to have access to.  It would seem that being really small 
creates even more problems making those connections.  I am a little doubtful 
about the article.  It would seem to me better to create a corrupted copy of 
something like a front side bus chipset, memory controller or some other 
component that handles data lines than create a new component that would then 
require a motherboard redesign to integrate correctly.  It would seem that as 
soon as the motherboard design was changed someone would wonder "hey, where are 
all those data lines going?"  It would also require less people in on the plan 
to corrupt or replace a device already in the design.  All you need is a way to 
intercept the original chip supply and insert your rogue devices.

On the opposite side of the argument, does anyone think it is strange that all 
of the companies mentioned in the article along with the PRC managed to get a 
simultaneous response back to Bloomberg.  Seems pretty pre-calculated to me.  
Or did some agency somewhere tell everyone they better shut up about the whole 
thing?

Steven Naslund
Chicago IL 


>Though Bloomberg didn't go out of their way to say it, the photos were
>"representative" of the chip supposedly found. Were they in possession
>of any hard evidence of the chips' existence, they'd have said so.
>
>Regards,
>Bill Herrin

Re: Buying IPv4 blocks

[Marco Davids via NANOG]

Op 04-10-18 om 22:07 schreef John Levine:


Even if you do have v6, some things like DNSSEC don't work very well
if you can't do them over v4.


Is that so?

--
Marco



signature.asc
Description: OpenPGP digital signature

Re: bloomberg on supermicro: sky is falling

[William Herrin]

On Thu, Oct 4, 2018 at 3:57 PM Mark Rousell  wrote:
> The mystery object in the pictures in the article seemed to me
> to (sort of) resemble a surface mount power conditioning
> capacitor.

Though Bloomberg didn't go out of their way to say it, the photos were
"representative" of the chip supposedly found. Were they in possession
of any hard evidence of the chips' existence, they'd have said so.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Not announcing (to the greater internet) loopbacks/PTP/infra - how ?

[Nick Hilliard]

William Herrin wrote on 04/10/2018 20:53:

I wonder if it would be useful to ask the IETF to assign a block of
"origination-only" IP addresses... IP addresses which by standard are
permitted to be the source of ICMP packets but which should be
unreachable by forward routing.


no - this would be abused for ddos.

Nick

Re: Buying IPv4 blocks

[John Levine]

In article 
 you 
write:
>
>If is a new US business and you are working internationally why not go
>simple and use IPv6 addresses?

Just a guess, but it's probably because they would like for the large
fraction of the net that is still v4 only to be able to contact them.

Even if you do have v6, some things like DNSSEC don't work very well
if you can't do them over v4.

Re: Oct. 3, 2018 EAS Presidential Alert test

[Sean Donelan]

Since I know network engineers are geeks, and can't stop themselves from 
looking...


On your iPhone (and android, and likely other cell phone OS), there are
detailed diagnostics logs. On your iPhone, look under

Settings->Privacy->Analytics->Analytics Data->awdd-

"awdd" means Apple Wireless Diagnostic Data.  In my iOS awdd file for 
October 3,there was something like this:


metriclogs {
  triggerTime: 1538590702067
  triggerId: 524356
  profileId: 174
  commCenterGSMCellBroadcastEvent {
   timestamp: 1538590702066
   message_id: 4370
   message_code: 0
   update_number: 0
   emergency_user_alert: false
  }
}

The trigger time is local time in milliseconds. That means my phone got
the cell broadcast at Wed Oct 03 2018 14:18:22, and displayed/alerted
on the phone 1 millisecond later.

Its usually a big file, so you'll need to scroll a long way. The entries
are in triggerTime order, which is the date/time, will help narrow down
where in the file.

That is the diagnostic data about the WEA Presidential Alert cell
broadcast message. The message_id 4370 is the GSM code for CMAS Alert
type Presidential. An Amber alert is code 4379 and other codes exist for
other messages.



If you didn't get an alert, you can look in the diagnostic file around 
that time for other things which might have prevented receiving an alert, 
e.g. no receiption, voice call in progress, roaming on carrier without 
WEA, etc.



In theory, Apple (iOS) and Alphabet (Android), and other manufacturers,
which collect diagnostic data analytics on handsets could create a 
nationwide report how well WEA performed based on actual data instead of 
anedoctal reports.

Re: Not announcing (to the greater internet) loopbacks/PTP/infra - how ?

[Karl Gerhard]

Hello Brandon,

instead of not announcing it you can send it to your upstream and tag it with 
no-export.
That way you can still see your router in traceroutes if the source ASN of the 
traceroute doesn't do uRPF.

If you don't have a separate range from which you assign PTP/loopback 
addresses, but your upstream offers a BGP blackhole community you can 
permanently blackhole your PTPs/loopbacks/infra at your upstream if you want to 
increase your security. Another way to keep your traceroutes pretty. However, 
if it's thousands of /32s then you should probably talk to your upstream before 
doing that. :)

Regards
Karl



--
*From:* Brandon Applegate [mailto:bran...@burn.net]
*Sent:* Thu, Oct 4, 2018 9:07 PM CEST
*To:* NANOG mailing list
*Subject:* Not announcing (to the greater internet) loopbacks/PTP/infra - how ?

> Hello,
>
> I’ve seen mention on this list and other places about keeping one’s PTPs / 
> loopbacks out of routing tables for security reasons.  Totally get this and 
> am on board with it.  What I don’t get - is how.  I’m going to list some of 
> my ideas below and the pros/cons/problems (that I can think of at least) for 
> them.
>
> - RFC 1918 for loopbacks and PTP
>   - Immediately “protects” from the internet at large, as they aren’t 
> routable.
>   - Traceroutes are miserable.
>
> - Use public block that is allocated to you (i.e. PI) - but not announced.
>   - So would this be a totally separate (from user/customer prefixes) 
> announcement and allocation ?  In other words, let’s say you were a small ISP 
> getting started.  You manage to get a /20 from a broker (IPv6 should be 
> “easy”).  Do you also now go out and get a /23 (I’m making these sizes up, 
> obviously all of these will vary based on ISP size, growth plan, etc.).  You 
> have the /23 registered to you (with proper rDNS delegation, WHOIS, etc.).  
> But you simply don’t announce it ? I’d say I need this /23 day one to even 
> build my network before it’s ready for customers.
>   - On the IPv6 front - would a RIR give you your /32 and then also a /48 
> (for loop/PTP) ?
>
> - Deaggregate and not announce your infra
>   - Bad net behavior out of the gate with this method.  The opposite of 
> elegant.
>   - Keeping with previously made up / arbitrary prefixes - for your /20 - 
> you’d end up announcing 2 x /23, 1 x /22 and 1 x /21.  I’m too lazy to 
> enumerate the IPv6 gymnastics, but with IPv6 you could “waste” a bit more to 
> get to boundaries that are a bit easier to work with I suppose.
>
> Thanks in advance for insights on this.
>
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 0641 D285 A36F 533A 73E5  2541 4920 533C C616 703A
> "For thousands of years men dreamed of pacts with demons.
> Only now are such things possible."
>

Re: bloomberg on supermicro: sky is falling

[Andrew Latham]

Supermicro's response at
https://www.supermicro.com/newsroom/pressreleases/2018/press181004_Bloomberg.cfm

On Thu, Oct 4, 2018 at 12:03 PM Randy Bush  wrote:

> re:
> https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
>
> from a side convo with a well known sec researcher:
>
> >> saw that a couple of years back when apple tossed them out.  so who
> >> do we know that is for sure not poisoned.  and therein lies the rub.
> > Yup
>
> truth is, i am surprised they had to add a chip, and one of the larger
> dies was not already trojaned.
>
> have visions of the chinese implant on box A fighting with the american
> implant on box B with occasional jabs from the israelis from box C.
>
> what i would love to see/know is how apple tries to vet the macs made in
> shenzhen.
>
> randy
>


-- 
- Andrew "lathama" Latham -

Re: Not announcing (to the greater internet) loopbacks/PTP/infra - how ?

[William Herrin]

On Thu, Oct 4, 2018 at 3:10 PM Brandon Applegate  wrote:
> I’ve seen mention on this list and other places about keeping one’s PTPs / 
> loopbacks out of routing tables for security reasons.  Totally get this and 
> am on board with it.  What I don’t get - is how.  I’m going to list some of 
> my ideas below and the pros/cons/problems (that I can think of at least) for 
> them.
>
> - RFC 1918 for loopbacks and PTP
>   - Immediately “protects” from the internet at large, as they aren’t 
> routable.
>   - Traceroutes are miserable.

Also breaks PMTUD which can break TCP for everybody whose packets
transit your router. So don't do this.


> - Use public block that is allocated to you (i.e. PI) - but not announced.

This works.


> - Deaggregate and not announce your infra

Not great.


Another option is to let it be announced but filter the packets at your border.

I wonder if it would be useful to ask the IETF to assign a block of
"origination-only" IP addresses... IP addresses which by standard are
permitted to be the source of ICMP packets but which should be
unreachable by forward routing.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: bloomberg on supermicro: sky is falling

[Matt Harris]

On Thu, Oct 4, 2018 at 2:26 PM William Herrin  wrote:

> On Thu, Oct 4, 2018 at 3:07 PM Denys Fedoryshchenko 
> wrote:
> > It would be better for them(AMZN, SMCI, AAPL)  to prove that these
> > events did not take place - in court.
>
> "Can't prove a negative."
>
> > In the opposite case, even if this article is full of inaccuracies,
> > judging by the discussions of security specialists, the scenario
> > indicated in the article is quite possible.
>
> The Bloomberg article described them as looking like 'signal
> conditioning couplers" on the motherboard. There is no such part on
> server boards but maybe they meant optoisolators or power conditioning
> capacitors. The former is a hard place to tweak the BMC from without a
> high probability of crashing it. The latter doesn't touch the data
> lines at all.
>

One wonders if, with the quality of BMC's in general being as low as it is,
and their security as bad, if any sort of extraneous hardware is necessary
to facilitate a compromise of a system where any of these BMCs is present.
Keep in mind many of these devices for some time included a "feature" where
telnet'ing to a specific port and typing in a short string would result in
a response containing a cleartext list of usernames and cleartext
passwords.  ;)

Re: bloomberg on supermicro: sky is falling

[Mark Rousell]

On 04/10/2018 20:26, William Herrin wrote:
> On Thu, Oct 4, 2018 at 3:07 PM Denys Fedoryshchenko  wrote:
>> It would be better for them(AMZN, SMCI, AAPL)  to prove that these
>> events did not take place - in court.
> "Can't prove a negative."

You can in effect do so by suing for defamation. It's then up to the
person who has made allegedly defamatory claims to prove their claims.
If they can't prove their claims in court then the claims are, in
effect, proven to be false.

However, I'm not sure that Amazon, Apple or Supermicro have actually
been defamed by the article in question. In other words, there could be
nothing to sue for. The PLA and Chinese government would have been
defamed (if the claims are untrue) but that's a different matter. Any
lawyers wants to offer an opinion?

> The Bloomberg article described them as looking like 'signal
> conditioning couplers" on the motherboard. There is no such part on
> server boards but maybe they meant optoisolators or power conditioning
> capacitors. The former is a hard place to tweak the BMC from without a
> high probability of crashing it. The latter doesn't touch the data
> lines at all.

The mystery object in the pictures in the article seemed to me to (sort
of) resemble a surface mount power conditioning capacitor. Note that
there was no suggestion that the mystery objects were connected in place
of capacitors; the article merely claimed that they were visually
disguised. They would obviously have to connect to data lines somewhere
to do what is claimed.

> They also quoted someone describing such a hack as being "like
> witnessing a unicorn jumping over a rainbow." I agree.

It doesn't seem so unreasonable to me. If true, this is not a matter of
fitting the mystery components to random hardware and hoping that they
go somewhere useful. Instead, these were specific models of hardware
being manufactured for specific customers for use in specific
locations/roles. In other words, it was near-guaranteed that the
hardware (or at least some of it) would end up being used in a location
that carried 'interesting' target data. As such, this would be, if true,
an example of very carefully targetted espionage, not some random lucky
miracle.

-- 
Mark Rousell

Re: Buying IPv4 blocks

[John Lee]

If is a new US business and you are working internationally why not go
simple and use IPv6 addresses?

John Lee

On Thu, Oct 4, 2018 at 10:59 AM Ross Tajvar  wrote:

> Thanks everyone who replied. I got many responses off-list, including a
> lot of positive endorsements for several different vendors. It's good to
> know there are so many reputable options.
>
> -Ross
>
> On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar  wrote:
>
>> Hi all,
>>
>> My US-based employer will be starting a new business unit soon that will
>> require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a
>> waitlist (though I'm not sure where they're getting new IPs from), but the
>> faster way is to buy blocks from people who already have them. I'm aware of
>> Hilco Streambank - are there any other auctions? If I want to buy via
>> private sale, does anyone know of ways to find sellers?
>>
>> Thanks,
>> Ross
>>
>
>

Re: Oct. 3, 2018 EAS Presidential Alert test

[Dan Lowe]

My wife and I, both on AT&T iPhones in the greater Cleveland area, received 
nothing. A co-worker of mine in Virginia got an alert, another in Texas did 
not. I believe the co-workers are both on AT&T.

I can't speak for the co-workers, but my wife and I do not have wifi calling 
enabled.

Dan


On Wed, Oct 3, 2018, at 2:52 PM, Andy Ringsmuth wrote:
> Did anyone on AT&T or an iPhone receive the test today? I believe it was 
> supposed to happen at 2:18 EDT, followed by one on broadcast radio at 
> 2:20 EDT.
> 
> I’m in CDT, so 1:18 and 1:20 p.m. CDT.
> 
> Message was heard on my desk radio at 1:21:35 p.m. CDT but as of the 
> sending of this at 1:52 p.m. CDT, nothing on phones. I have an office 
> full of AT&T iPhones and not a single one of them alerted.
> 
> FEMA says https://www.fema.gov/emergency-alert-test
> 
> "Cell towers will broadcast the WEA test for approximately 30 minutes 
> beginning at 2:18 p.m. EDT. During this time, WEA compatible cell phones 
> that are switched on, within range of an active cell tower, and whose 
> wireless provider participates in WEA should be capable of receiving the 
> test message. Some cell phones will not receive the test message, and 
> cell phones should only receive the message once."
> 
> My wife, with a Sprint iPhone, received the test.
> 
> 
> 
> Andy Ringsmuth
> 5609 Harding Drive
> Lincoln, NE 68521-5831
> (402) 304-0083
> a...@andyring.com
> 

RE: Oct. 3, 2018 EAS Presidential Alert test

[Cooke, David]

Not received here but the BBC did apparently...

https://www.bbc.com/news/technology-45730367

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Bill Woodcock
Sent: Wednesday, October 03, 2018 5:17 PM
To: nanog@nanog.org list
Subject: Re: Oct. 3, 2018 EAS Presidential Alert test

Received at roughly 12:15 Pacific time, AT&T / IOS / Berkeley CA.

-Bill

BAE Systems will collect and process information about you that may be subject 
to data protection laws. For more information about how we use and disclose 
your personal information, how we protect your information, our legal basis to 
use your information, your rights and who you can contact, please refer to the 
relevant sections of our Privacy note at 
www.baesystems.com/en/cybersecurity/privacy 


Please consider the environment before printing this email. This message should 
be regarded as confidential. If you have received this email in error please 
notify the sender and destroy it immediately. Statements of intent shall only 
become binding when confirmed in hard copy by an authorised signatory. The 
contents of this email may relate to dealings with other companies under the 
control of BAE Systems PLC, details of which can be found at 
http://www.baesystems.com/Businesses/index.htm.

Re: Not announcing (to the greater internet) loopbacks/PTP/infra - how ?

[Jason Lixfeld]

> On Oct 4, 2018, at 3:07 PM, Brandon Applegate  wrote:
> 
> Thanks in advance for insights on this.

If you’re MPLS enabled, one implementation could see place the loop/infra/p2p 
in the global table and customer/internet traffic inside a VRF.

Re: bloomberg on supermicro: sky is falling

[valdis . kletnieks]

On Thu, 04 Oct 2018 15:26:15 -0400, William Herrin said:

> The Bloomberg article described them as looking like 'signal
> conditioning couplers" on the motherboard. There is no such part on
> server boards but maybe they meant optoisolators or power conditioning
> capacitors.

You overlook the obvious case - that it *looks* like Yet Another Filter Cap
but it's actually a microcontroller wired into a useful SPI bus


pgpI1S17L_AoV.pgp
Description: PGP signature

Re: bloomberg on supermicro: sky is falling

[William Herrin]

On Thu, Oct 4, 2018 at 3:07 PM Denys Fedoryshchenko  wrote:
> It would be better for them(AMZN, SMCI, AAPL)  to prove that these
> events did not take place - in court.

"Can't prove a negative."

> In the opposite case, even if this article is full of inaccuracies,
> judging by the discussions of security specialists, the scenario
> indicated in the article is quite possible.

The Bloomberg article described them as looking like 'signal
conditioning couplers" on the motherboard. There is no such part on
server boards but maybe they meant optoisolators or power conditioning
capacitors. The former is a hard place to tweak the BMC from without a
high probability of crashing it. The latter doesn't touch the data
lines at all.

They also quoted someone describing such a hack as being "like
witnessing a unicorn jumping over a rainbow." I agree.

Regards,
Bill Herrin

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Not announcing (to the greater internet) loopbacks/PTP/infra - how ?

[Pierre Emeriaud]

Le jeu. 4 oct. 2018 à 21:12, Brandon Applegate  a écrit :
>
> I’ve seen mention on this list and other places about keeping one’s PTPs / 
> loopbacks out of routing tables for security reasons.  Totally get this and 
> am on board with it.  What I don’t get - is how.  I’m going to list some of 
> my ideas below and the pros/cons/problems (that I can think of at least) for 
> them.

> - Use public block that is allocated to you (i.e. PI) - but not announced.

this is what we do. We are lucky enough to have plenty of address
space which was quite correctly assigned in the first place. This is
nice, except for one thing: other networks having urpf towards us. It
makes traceroutes from their side to ours useless.

Other than that, we use bgpmon to monitor for the absence of
advertisements /leaks for those internal prefixes. Works really well.

Not announcing (to the greater internet) loopbacks/PTP/infra - how ?

[Brandon Applegate]

Hello,

I’ve seen mention on this list and other places about keeping one’s PTPs / 
loopbacks out of routing tables for security reasons.  Totally get this and am 
on board with it.  What I don’t get - is how.  I’m going to list some of my 
ideas below and the pros/cons/problems (that I can think of at least) for them.

- RFC 1918 for loopbacks and PTP
  - Immediately “protects” from the internet at large, as they aren’t routable.
  - Traceroutes are miserable.

- Use public block that is allocated to you (i.e. PI) - but not announced.
  - So would this be a totally separate (from user/customer prefixes) 
announcement and allocation ?  In other words, let’s say you were a small ISP 
getting started.  You manage to get a /20 from a broker (IPv6 should be 
“easy”).  Do you also now go out and get a /23 (I’m making these sizes up, 
obviously all of these will vary based on ISP size, growth plan, etc.).  You 
have the /23 registered to you (with proper rDNS delegation, WHOIS, etc.).  But 
you simply don’t announce it ? I’d say I need this /23 day one to even build my 
network before it’s ready for customers.
  - On the IPv6 front - would a RIR give you your /32 and then also a /48 (for 
loop/PTP) ?

- Deaggregate and not announce your infra
  - Bad net behavior out of the gate with this method.  The opposite of elegant.
  - Keeping with previously made up / arbitrary prefixes - for your /20 - you’d 
end up announcing 2 x /23, 1 x /22 and 1 x /21.  I’m too lazy to enumerate the 
IPv6 gymnastics, but with IPv6 you could “waste” a bit more to get to 
boundaries that are a bit easier to work with I suppose.

Thanks in advance for insights on this.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
0641 D285 A36F 533A 73E5  2541 4920 533C C616 703A
"For thousands of years men dreamed of pacts with demons.
Only now are such things possible."

Re: bloomberg on supermicro: sky is falling

[Denys Fedoryshchenko]

On 2018-10-04 21:52, Scott Weeks wrote:

--- matlock...@gmail.com wrote:
From: Ken Matlock 

Would be remiss in our duties if we didn't also link
AWS' blog, in response to the Bloomberg article.
--


Every company and the Chinese gov't is saying "no,
Bloomberg is wrong":

https://www.bloomberg.com/news/articles/2018-10-04/the-big-hack-amazon-apple-supermicro-and-beijing-respond

Can't wait to see how this evolves...

scott
It would be better for them(AMZN, SMCI, AAPL)  to prove that these 
events did not take place - in court.
In the opposite case, even if this article is full of inaccuracies, 
judging by the discussions of security specialists, the scenario 
indicated in the article is quite possible.
Unpopulated SOIC-8 near populated SOIC-16 flash for BMC firmware is 
sweet spot for custom MCU - snooping on flash SPI(most likely) bus and 
probably altering some data.
At the same time there will be a good precedent, if this article is 
fabricated - such journalists need to be taught a lesson.

And if they wont go to the court, there is something to think about.

Re: bloomberg on supermicro: sky is falling

[Scott Weeks]

--- matlock...@gmail.com wrote:
From: Ken Matlock 

Would be remiss in our duties if we didn't also link 
AWS' blog, in response to the Bloomberg article.
--


Every company and the Chinese gov't is saying "no, 
Bloomberg is wrong":

https://www.bloomberg.com/news/articles/2018-10-04/the-big-hack-amazon-apple-supermicro-and-beijing-respond

Can't wait to see how this evolves...

scott

Re: bloomberg on supermicro: sky is falling

[Ken Matlock]

Would be remiss in our duties if we didn't also link AWS' blog, in response
to the Bloomberg article.

In short, AWS refutes many of Bloomberg's reporting in the article.

https://aws.amazon.com/blogs/security/setting-the-record-straight-on-bloomberg-businessweeks-erroneous-article/

Ken

On Thu, Oct 4, 2018 at 11:03 AM Randy Bush  wrote:

> re:
> https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies
>
> from a side convo with a well known sec researcher:
>
> >> saw that a couple of years back when apple tossed them out.  so who
> >> do we know that is for sure not poisoned.  and therein lies the rub.
> > Yup
>
> truth is, i am surprised they had to add a chip, and one of the larger
> dies was not already trojaned.
>
> have visions of the chinese implant on box A fighting with the american
> implant on box B with occasional jabs from the israelis from box C.
>
> what i would love to see/know is how apple tries to vet the macs made in
> shenzhen.
>
> randy
>

bloomberg on supermicro: sky is falling

[Randy Bush]

re: 
https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies

from a side convo with a well known sec researcher:

>> saw that a couple of years back when apple tossed them out.  so who
>> do we know that is for sure not poisoned.  and therein lies the rub.
> Yup

truth is, i am surprised they had to add a chip, and one of the larger
dies was not already trojaned.

have visions of the chinese implant on box A fighting with the american
implant on box B with occasional jabs from the israelis from box C.

what i would love to see/know is how apple tries to vet the macs made in
shenzhen.

randy

Re: Buying IPv4 blocks

[Matt Harris]

On Thu, Oct 4, 2018 at 11:20 AM Ross Tajvar  wrote:

> I'm rolling my eyes. We'll be using IPv6, but obviously we need IPv4 too.
>
> On Thu, Oct 4, 2018, 12:00 PM John Lee  wrote:
>
>> If is a new US business and you are working internationally why not go
>> simple and use IPv6 addresses?
>>
>> John Lee
>>
>
What do you mean you want to be able to reach and be reachable by more than
20% of the internet?

I'm all for IPv6 deployment and I go so far as to push it onto customers
(and configure things correctly so that they have a good IPv6 experience)
who otherwise wouldn't even know anything about it or care at all, but to
pretend that one can subsist without at least some IPv4 space to facilitate
translation at this stage is just unrealistic.

- Matt

Re: Buying IPv4 blocks

[Ross Tajvar]

I'm rolling my eyes. We'll be using IPv6, but obviously we need IPv4 too.

On Thu, Oct 4, 2018, 12:00 PM John Lee  wrote:

> If is a new US business and you are working internationally why not go
> simple and use IPv6 addresses?
>
> John Lee
>
> On Thu, Oct 4, 2018 at 10:59 AM Ross Tajvar  wrote:
>
>> Thanks everyone who replied. I got many responses off-list, including a
>> lot of positive endorsements for several different vendors. It's good to
>> know there are so many reputable options.
>>
>> -Ross
>>
>> On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar  wrote:
>>
>>> Hi all,
>>>
>>> My US-based employer will be starting a new business unit soon that will
>>> require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a
>>> waitlist (though I'm not sure where they're getting new IPs from), but the
>>> faster way is to buy blocks from people who already have them. I'm aware of
>>> Hilco Streambank - are there any other auctions? If I want to buy via
>>> private sale, does anyone know of ways to find sellers?
>>>
>>> Thanks,
>>> Ross
>>>
>>
>>

Re: Buying IPv4 blocks

[Ross Tajvar]

Thanks everyone who replied. I got many responses off-list, including a lot
of positive endorsements for several different vendors. It's good to know
there are so many reputable options.

-Ross

On Mon, Oct 1, 2018 at 9:57 PM, Ross Tajvar  wrote:

> Hi all,
>
> My US-based employer will be starting a new business unit soon that will
> require IPv4 addresses (aiming for a /22 to start with). I know ARIN has a
> waitlist (though I'm not sure where they're getting new IPs from), but the
> faster way is to buy blocks from people who already have them. I'm aware of
> Hilco Streambank - are there any other auctions? If I want to buy via
> private sale, does anyone know of ways to find sellers?
>
> Thanks,
> Ross
>