Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Carl Byington via NANOG]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2019-02-25 at 17:04 +1100, Mark Andrews wrote:
> I would also note that a organisation can deploy RFC 5011 for their
> own zones and have their own equipment use DNSKEYs managed using RFC
> 5011 for their own zones.  This isolates the organisation's equipment
> from the parent zone's management practices.

I want a registrar that can use TOTP 2fa for updates, but that
interferes with automated KSK key rollovers. Are there any registrars
that use rfc5011 to allow automated KSK key rollovers, combined with
TOTP 2fa for web based updates like the initial transition to a secure
zone, NS record changes, etc.?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlx1aWgACgkQL6j7milTFsF9mACfVIXUZNLTOEyzbjneuZDeIBEg
2GUAnjoWsNZXtu0PgTuTvPwK0Je9DpCG
=nZy7
-END PGP SIGNATURE-

Re: Please run windows update now

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, 2017-05-16 at 10:33 -0500, Brad Knowles wrote:

> > In the American approach, if there are a significant number of road
> fatalities, then it's the drivers own fault and they should have taken
> more care.  They are automatically to blame for their own failure.

Not in all parts of America. Highway 18 here just got a full metal
barrier separating the opposing traffic in much of the 4 lane section.
55 mph limit, lots of tight curves, about 18 inches separation between
the opposing traffic, and a bunch of drivers that don't know how to
drive around a curve. Someone got tired of all the head on crashes, so
they "fixed" the road.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlkb1NQACgkQL6j7milTFsESFwCfY956WrGCswGc2CNPt1nHhGF0
WGYAnRsj+MZ937fiKjEbfNvCEiyUBx8o
=T1L3
-END PGP SIGNATURE-

Re: Microsoft O365 labels nanog potential fraud?

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2017-03-30 at 15:21 +1100, Mark Andrews wrote:
> Well you should be checking the correct TXT record for SPF.

> dig marketo-email.box.com txt +short
> "v=spf1 ip4:192.28.147.168 ip4:192.28.147.169 -all"

Hm, a closer reading of rfc7489 sheds some light on this:

Would dmarc-spf consider marketo-email.box.com to be 'aligned' with the
from header email.box.com domain? It is neither a child nor parent of
email.box.com.

The _dmarc txt record for email.box.com has no aspf: tag, so we should
be operating in spf/dkim relaxed alignment mode.

rfc7489, when discussing relaxed identifier alignment, says the
"Organizational Domain" of the identifiers must match. But there is no
explicit example of that. Instead, the examples talk about one of the
identifiers being a parent of the other identifier.

The envelope from marketo-email.box.com and the 2822 header from
email.box.com have the same box.com organizational domain. If we ignore
the examples in rfc7489, it looks like this is NOT broken.

I am probably not the only one that wrote code matching on the
parent/child relationship of the identifiers, rather than computing the
Organizational Domains and matching those.

As Mr. Hodgson pointed out, box.com has very recently started sending
mail with multiple dkim signatures, header.d=email.box.com and 2822
header from = email.box.com.

Now off to fix my code.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAljcpTkACgkQL6j7milTFsHROACfYDmp1Vv7kUwWZQ9m1YCgSB+C
y9kAnitNWUvORSQNgOv5AsyUL35Y8Yhc
=CDq3
-END PGP SIGNATURE-

Re: Microsoft O365 labels nanog potential fraud?

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2017-03-29 at 09:24 -0700, Alan Hodgson wrote:

> So for DMARC+SPF to pass not only must the message come from a source
> authorized by the envelope sender domain, but that domain must be the
> same domain (or parent domain or subdomain) of the header From:
> address.

> For DMARC+DKIM to pass, the DKIM signature must pass and the DKIM
> signing domain must be the same domain (or parent domain or subdomain)
> of the header From: address.

> Again, DMARC requires only one or the other mechanism to pass. So
> messages forwarded intact should be OK if they have an aligned DKIM
> signature.


Brad Knowles wrote:

> ...and it's easy to set things up in a way that you wind up shooting
> yourself in the foot -- and possibly with a large thermonuclear
> device.


For an example of that (unless I am misunderstanding something), we
have:

 --> Hello marketo-email.box.com [192.28.147.169], pleased to meet you
 <-- MAIL FROM:<$mun...@marketo-email.box.com>
 <-- RCPT TO: ...

dkim pass header.d=mktdns.com
rfc2822 from header = $mun...@email.box.com


dig _dmarc.email.box.com txt +short
"v=DMARC1; p=reject; ..."

dig email.box.com txt +short
"v=spf1 ip4:192.28.147.168 -all"

So given the dmarc reject policy, it needs to pass either spf (which
fails 192.28.147.168 != 192.28.147.169), or dkim (which fails since it
is not signed by anything related to email.box.com.

Am I missing something, or is that just broken?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAljcJe4ACgkQL6j7milTFsFUMwCfT4Wgr0kUHjhVPvi0wER3Nfz+
osAAni5YH25tTCGk49jESd5NOKVk3Okd
=JL7y
-END PGP SIGNATURE-

Re: Microsoft O365 labels nanog potential fraud?

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2017-03-29 at 11:32 -0400, William Herrin wrote:

> The gold standard, Spamassassin, does not. Indeed, the message to
> which I reply was scored by spam assassin as "SPF_PASS" even though
> you do not include NANOG's servers in the SPF record for
> tnetconsulting.net.

The message from Mr. Taylor (to which Mr. Herrin is replying) arrived
here with:

Return-path: 
From: Grant Taylor via NANOG 
Reply-to: Grant Taylor 

So an SPF implementation that checks either or both of the (rfc2821
envelope from / rfc2822 header from) domains will pass.

The original was DKIM signed by d=tnetconsulting.net (c=simple/simple -
you might want to change that) but of course that signature was broken
by the nanog list handling.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAljb2dEACgkQL6j7milTFsGoxwCePikWwzhrqSLFV3QQIKNR8FfO
eoAAnjjH7TgYcTSJC8DWe2l139iQfkkI
=SEM6
-END PGP SIGNATURE-

Re: IoT security

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2017-02-08 at 08:30 -0800, Damian Menscher wrote:
> So here's a modest proposal: log in as root and brick the
> device.

I strongly suspect that when the problem gets bad *enough*, someone will
do exactly that. Yes, it is illegal in many places. Since when has the
fact that any particular act is illegal been sufficient to deter
*everyone*?

People still drive while drunk.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlibzdIACgkQL6j7milTFsH/WgCdEvde+zMvm8lRUyx2ay3EltZT
97kAn3Hl2tjPe2eUqiagDXxlE75OO/Xg
=W+Cq
-END PGP SIGNATURE-

Re: DOT FRA website broken on ipv6

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2017-02-02 at 10:22 -0800, Ca By wrote:
> Anyone have a contact at DOT or FRA that can solve this?  It would be
> really nice if they remove the DNS  record on www.fra.dot.gov
> until it works correctly, customers are complaining

Their SOA record suggests hostmas...@dot.gov.

You could temporarily (ab)use a bind rpz zone to override that.

www.fra.dot.gov A 204.68.194.250

That rpz A record will suppress the real  record.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAliWaigACgkQL6j7milTFsFnagCcD8Cxq6rW9fmP4yREA2Vbt4FU
XQQAniIhLcnUUmsfzkyY9mZzsBto2wKm
=ePCp
-END PGP SIGNATURE-

Re: pay.gov and IPv6

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2016-11-21 at 11:26 +1100, Mark Andrews wrote:
> And the advertised MSS was what?  On my box I'm seeing 1220 for
> IPv6 compared with 1460 for IPv4.  1220 shouldn't see PMTU problems.

  --> 2001:8d8:100f:f000::2d5 syn w/ mss 1440
  <-- 2001:8d8:100f:f000::2d5 syn,ack w/ mss 1420
  --> 2001:8d8:100f:f000::2d5 ack
  --> 2001:8d8:100f:f000::2d5 GET / HTTP/1.1
  <-- 2001:8d8:100f:f000::2d5 ack
  <-- 2001:8d8:100f:f000::2d5 data...


data is a 1480 byte ipv6 packet:

ip6.header.payload.length = 1440 which is the tcp packet
tcp.header.length = 32 bytes
tcp.data.size = 1408 bytes (http response)


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlgyRUYACgkQL6j7milTFsH8tgCeLB9E9C2pjFqgp1w2YpipmvzZ
ib4Ani/cQmAgEo3QPfA9hMntGq4VLoO/
=mmCW
-END PGP SIGNATURE-

Re: pay.gov and IPv6

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, 2016-11-20 at 10:51 +0100, JORDI PALET MARTINEZ wrote:
> For example, you will not get this working if you have a lower MTU
> than 1.500, which is quite normal, not just for tunnels, but also
> because the PPP/others encapsulation in many access links:

> http://diskmakerx.com/

curl -6 -v http://diskmakerx.com/

That works here via an he.net tunnel. Perhaps 1and1 fixed something.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlgyOp4ACgkQL6j7milTFsFslACfaRbslKuUHrxGJyuI+j8X/Sle
AZ8AoIg2wF/GWBdDtphQSuD9/gGMDfOA
=4nAp
-END PGP SIGNATURE-

Re: pay.gov and IPv6

[Carl Byington]

> > I am working with pay.gov.c...@clev.frb.org, trying to explain the
> problem.

The intersection of government bureaucracy and technical issues is
frustrating to say the least. I just sent the message below, but have no
expectation that it will change anything. 

==

On Fri, 2016-11-18 at 12:39 +, CLEV Pay Gov wrote:
> It would be best to discuss this via phone.  Please contact our help
> desk at the number below and we could see if there's anything we could
> do over the phone to help troubleshoot.

That is hopeless. Verbal technical discussions rarely work unless both
sides can see the same text. Have you ever tried (while talking on the
phone) to get someone to type in clev.frb.org without making a bunch of
mistakes in the spelling??

Anyway, just for my amusement, I did call 800-624-1373, Option #2, and
am on the line now, trying to explain this. 10 minutes and counting. Ok,
there does not seem to be any overall ticket for "pay.gov does not work
at all". They refuse to open a tech support ticket.


> If not, we may need to open a ticket for our technical support.

Please open a ticket, and attach the following text for your tech
support folks. Alternatively, have them look at the "pay.gov and ipv6"
thread on nanog:

http://mailman.nanog.org/pipermail/nanog/2016-November/thread.html



www.pay.gov has an IPv6 address of 2605:3100:fffd:100::15, but that
machine or its upstream routers are filtering icmpv6 messages. That web
site is not accessible from systems with an MTU of 1280 bytes.

The test case is:

echo -e 'GET /public/home HTTP/1.0\n' | \
openssl s_client -servername www.pay.gov -ign_eof -connect \
'[2605:3100:fffd:100::15]:443'

Run that (or just use a browser to try https://www.pay.gov) from a
system with a 1500 byte MTU, and it works. Run it from a system with
upstream connectivity via a tunnel, so the path MTU is smaller, and it
fails. Such tunnels are common for IPv6.

Please stop filtering icmpv6.

Re: pay.gov and IPv6

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2016-11-17 at 15:32 -0500, Lee wrote:
> That's fine, but until someone is willing to work with them don't
> expect it to get fixed.

I am working with pay.gov.c...@clev.frb.org, trying to explain the
problem. They seem to think I should provide "application name and ID"
before they can research this. I responded as below. I will let you know
if there is any progress on this. It is 100% reproducible here - and
should be reproducible from anywhere with a slightly smaller than normal
MTU.



We try to get to https://www.pay.gov/public/home - which fails. I
presume that is before there is any application name or ID.

Try to reach that page from a browser on a machine with ipv6
connectivity that goes thru a tunnel with a 1300 byte MTU. It will fail.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlguP8oACgkQL6j7milTFsFgrQCfY2QLE0njiSRIILTzR4Fjpk3c
F3AAnjZj8+3W51Qr9e1oGWAxrUC8Pnf3
=UpN0
-END PGP SIGNATURE-

Re: pay.gov and IPv6

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2016-11-16 at 20:59 +, Matthew Kaufman wrote:
> I fixed it (and Netflix) by turning off IPv6 for all my users... but
> any chance this is a path MTU issue causing the apparent hang?

I fixed it by using the rpz feature of bind to disable the  record
for www.pay.gov. I lookup the real A record, and then put

www.pay.gov IN A %s

into the local rpz zone. That suppresses the  record, so local
clients are forced into IPv4 for that site. That allows them to use IPv6
for other sites.

path MTU - hm, I need to check that.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlgsz0YACgkQL6j7milTFsEbpwCgiJwZm3R/0VowqNFu4afHwPRq
siwAmwdAj2YCLnlNQAs5Q5E5hcthaoiP
=yqXb
-END PGP SIGNATURE-

pay.gov and IPv6

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Following up on a two year old thread, one of my clients just hit this
problem. The failure is not that www.pay.gov is not reachable over ipv6
(2605:3100:fffd:100::15). They accept (TCP handshake) the port 443
connection, but the connection then hangs waiting for the TLS handshake.

openssl s_client -connect www.pay.gov:443

openssl s_client -servername www.pay.gov -connect 199.169.192.21:443

Browsers (at least firefox) see that as a very slow site, and it does
not trigger their happy eyeballs fast failover to ipv4.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlgrjDEACgkQL6j7milTFsG8OwCgh5yRxxZHskjL4HVhzxIEmenA
LQgAniRMcYf/DIcg+8ve55MxUgrUbmzC
=MS8j
-END PGP SIGNATURE-

pay.gov and IPv6

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Following up on a two year old thread, one of my clients just hit this
problem. The failure is not that www.pay.gov is not reachable over ipv6
(2605:3100:fffd:100::15). They accept (TCP handshake) the port 443
connection, but the connection then hangs waiting for the TLS handshake.

openssl s_client -connect www.pay.gov:443

openssl s_client -servername www.pay.gov -connect 199.169.192.21:443

Browsers (at least firefox) see that as a very slow site, and it does
not trigger their happy eyeballs fast failover to ipv4.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlgoo9AACgkQL6j7milTFsEIhwCfS2nVWDwjGk5LLaPpAntLC8la
RpMAniYdP2OmTcx4+lJmaIu538LK9pqJ
=SOdT
-END PGP SIGNATURE-