Fkiws with destination port 0 and TCP SYN flag set

[Maqbool Hashim]

Hi,



I am doing some flow analysis within our network primarily for understanding 
application flows to aid in network segregation activity and mainly understand 
what is going on inside the network.  To do this I have been using netflow 
where the switches/firewalls support it.  In some cases I have used a monitor 
port and fed full packet capture into the nfdump toolset for conversion into 
flows.

There is a portion of our network where the switches only support sflow which 
is not ideal, but hopefully will be able to gather enough data over time to be 
useful.  One of the things I was trying to identify was flow initiation, i.e. 
the client and server in the flow- so filtered for TCP packets with SYN flag 
set.



It was at this point that I saw TCP SYN packets with a destination port of 0.  
I have seen this discussed before in this thread  
http://www.gossamer-threads.com/lists/nanog/users/155141



It was stated in that thread that netflow reports source/dest port 0 for 
non-initial fragments.  My question was is this what I am seeing here, so any 
SYN packet with dest port 0 is a non-initial fragment seen by the tool?  
Therefore should I always see a corresponding response with Ack and Reset flags 
set?  I do see a set of flows with R and A set with a source port of 0, all the 
dest port 0 flows have the SYN flag set, but it's hard to find ones that match 
a SYN packet due to only receiving a sample of flows.



Some notes on the setup:

Capture is from inside one VLAN
Switches are sending sflow back to analysis tools, sampling rate of 1/1024 
packets
Using nfdump suite of tools for analysis. sfcapd as as the collector



Thinking about this, is what I am seeing a symptom of the fact that the tools 
don't see all packets, i.e. the tools don't see the initial fragment due to 
sampling.  However I still don't quite understand it appearing with the SYN 
flag set?



I am starting to think that for these purposes I might be better abandoning 
sflow and go with setting up collectors on the switches to get full flow 
information for my purposes.



Any clarification/input much appreciated.



Regards



MH

Re: Fkiws with destination port 0 and TCP SYN flag set

[Roland Dobbins]

On 17 Jun 2015, at 10:44, Maqbool Hashim wrote:

It was stated in that thread that netflow reports source/dest port 0 
for non-initial fragments.


Fragmentation in this context only applies to UDP packets.

If the destination of a TCP SYN is being reported as 0 (what's the 
source port?), either it's a reporting artifact of some kind or in fact 
a SYN destined to TCP/0 (we see this with SYN-floods, sometimes, as well 
as with attacks attempting to bypass ACL/firewall rules and related to 
compromise).


---
Roland Dobbins 

Re: Fkiws with destination port 0 and TCP SYN flag set

[Maqbool Hashim]

Hi

Thanks for the response.  There are lots of different source ports all above 
10,000 (e.g. 42628,42927,39050).  It is always two redhat machines generating 
the traffic, can't be 100% sure due to the sampling but pretty sure the capture 
has been running for 24 hours or so.It is always the same destination 
servers and in normal operations these source and destination hosts do have a 
bunch of legitimate flows between them.  I was leaning towards it being a 
reporting artifact, but it's interesting that there are a whole set of Ack 
Reset packets from the destination hosts with a source port of 0 also.  Does 
this not indicate that it probably isn't a reporting artifact?

Maybe I need to setup collectors and span ports on all the switches involved to 
get to the bottom of this.  Just feeling like we need to look at *all* the 
packets not the sample!

Regards,

MH


From: NANOG  on behalf of Roland Dobbins 

Sent: 17 June 2015 10:07
To: nanog@nanog.org
Subject: Re: Fkiws with destination port 0 and TCP SYN flag set

On 17 Jun 2015, at 10:44, Maqbool Hashim wrote:

> It was stated in that thread that netflow reports source/dest port 0
> for non-initial fragments.

Fragmentation in this context only applies to UDP packets.

If the destination of a TCP SYN is being reported as 0 (what's the
source port?), either it's a reporting artifact of some kind or in fact
a SYN destined to TCP/0 (we see this with SYN-floods, sometimes, as well
as with attacks attempting to bypass ACL/firewall rules and related to
compromise).

---
Roland Dobbins 

Re: Fkiws with destination port 0 and TCP SYN flag set

[Marcin Cieslak]

On Wed, 17 Jun 2015, Maqbool Hashim wrote:

> It is always the same destination servers and in normal operations
> these source and destination hosts do have a bunch of legitimate flows
> between them.  I was leaning towards it being a reporting artifact,
> but it's interesting that there are a whole set of Ack Reset packets
> from the destination hosts with a source port of 0 also.

So the destination host is sending ACK+RST with the *source* port
set to zero, or the *destination* port?

> Does this not indicate that it probably isn't a reporting artifact?

I would just tcpdump on one of the source machines to find out.

~Marcin

Re: Fkiws with destination port 0 and TCP SYN flag set

[Roland Dobbins]

On 17 Jun 2015, at 11:23, Maqbool Hashim wrote:

Maybe I need to setup collectors and span ports on all the switches 
involved to get to the bottom of this.  Just feeling like we need to 
look at *all* the packets not the sample!


Concur 100%.

---
Roland Dobbins 

Re: Fkiws with destination port 0 and TCP SYN flag set

[Maqbool Hashim]

Hi,

The destination host is sending an ACK+RST with the source port set to zero.  
The destination IP is always one of the two hosts that are generating the SYN 
packets with a destination port of 0.  The destination port however is hard to 
match up to a source port in the original SYN packet due to the fact that we 
don't have all the packets.

It's actually going to be difficult to get the access and procedural sign off 
etc. to run tcpdump on the machines involved.  What might be easier is to set 
up a span port for the hosts access port on the switch and grab that via the 
collector laptop I have.

Thanks,

MH


From: Marcin Cieslak 
Sent: 17 June 2015 10:30
To: Maqbool Hashim
Cc: nanog@nanog.org
Subject: Re: Fkiws with destination port 0 and TCP SYN flag set

On Wed, 17 Jun 2015, Maqbool Hashim wrote:

> It is always the same destination servers and in normal operations
> these source and destination hosts do have a bunch of legitimate flows
> between them.  I was leaning towards it being a reporting artifact,
> but it's interesting that there are a whole set of Ack Reset packets
> from the destination hosts with a source port of 0 also.

So the destination host is sending ACK+RST with the *source* port
set to zero, or the *destination* port?

> Does this not indicate that it probably isn't a reporting artifact?

I would just tcpdump on one of the source machines to find out.

~Marcin

Re: Fkiws with destination port 0 and TCP SYN flag set

[Pavel Odintsov]

Hello!

Looks like it's silly hping3 flood:

12:43:08.961024 IP 192.168.0.127.10562 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961031 IP 192.168.0.127.10563 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961039 IP 192.168.0.127.10564 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961046 IP 192.168.0.127.10565 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961054 IP 192.168.0.127.10566 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961062 IP 192.168.0.127.10567 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961070 IP 192.168.0.127.10568 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961077 IP 192.168.0.127.10569 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961085 IP 192.168.0.127.10570 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961093 IP 192.168.0.127.10571 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961101 IP 192.168.0.127.10572 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961108 IP 192.168.0.127.10573 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961116 IP 192.168.0.127.10574 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961123 IP 192.168.0.127.10575 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961131 IP 192.168.0.127.10576 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961139 IP 192.168.0.127.10577 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961146 IP 192.168.0.127.10578 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961154 IP 192.168.0.127.10579 > 216.239.32.21.0: Flags [.],
win 512, length 0

Just try:
hping3 --flood target_host.

On Wed, Jun 17, 2015 at 12:34 PM, Maqbool Hashim  wrote:
> Hi,
>
> The destination host is sending an ACK+RST with the source port set to zero.  
> The destination IP is always one of the two hosts that are generating the SYN 
> packets with a destination port of 0.  The destination port however is hard 
> to match up to a source port in the original SYN packet due to the fact that 
> we don't have all the packets.
>
> It's actually going to be difficult to get the access and procedural sign off 
> etc. to run tcpdump on the machines involved.  What might be easier is to set 
> up a span port for the hosts access port on the switch and grab that via the 
> collector laptop I have.
>
> Thanks,
>
> MH
>
> 
> From: Marcin Cieslak 
> Sent: 17 June 2015 10:30
> To: Maqbool Hashim
> Cc: nanog@nanog.org
> Subject: Re: Fkiws with destination port 0 and TCP SYN flag set
>
> On Wed, 17 Jun 2015, Maqbool Hashim wrote:
>
>> It is always the same destination servers and in normal operations
>> these source and destination hosts do have a bunch of legitimate flows
>> between them.  I was leaning towards it being a reporting artifact,
>> but it's interesting that there are a whole set of Ack Reset packets
>> from the destination hosts with a source port of 0 also.
>
> So the destination host is sending ACK+RST with the *source* port
> set to zero, or the *destination* port?
>
>> Does this not indicate that it probably isn't a reporting artifact?
>
> I would just tcpdump on one of the source machines to find out.
>
> ~Marcin



-- 
Sincerely yours, Pavel Odintsov

Re: Fkiws with destination port 0 and TCP SYN flag set

[Roland Dobbins]

On 17 Jun 2015, at 11:34, Maqbool Hashim wrote:

What might be easier is to set up a span port for the hosts access 
port on the switch and grab that via the collector laptop I have.


It's better to collect as much information you have without perturbing 
the systems involved, anyways.


---
Roland Dobbins 

Re: Fkiws with destination port 0 and TCP SYN flag set

[Maqbool Hashim]

Hmm, no flags set in your output though?


From: Pavel Odintsov 
Sent: 17 June 2015 10:44
To: Maqbool Hashim
Cc: Marcin Cieslak; nanog@nanog.org
Subject: Re: Fkiws with destination port 0 and TCP SYN flag set

Hello!

Looks like it's silly hping3 flood:

12:43:08.961024 IP 192.168.0.127.10562 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961031 IP 192.168.0.127.10563 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961039 IP 192.168.0.127.10564 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961046 IP 192.168.0.127.10565 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961054 IP 192.168.0.127.10566 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961062 IP 192.168.0.127.10567 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961070 IP 192.168.0.127.10568 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961077 IP 192.168.0.127.10569 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961085 IP 192.168.0.127.10570 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961093 IP 192.168.0.127.10571 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961101 IP 192.168.0.127.10572 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961108 IP 192.168.0.127.10573 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961116 IP 192.168.0.127.10574 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961123 IP 192.168.0.127.10575 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961131 IP 192.168.0.127.10576 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961139 IP 192.168.0.127.10577 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961146 IP 192.168.0.127.10578 > 216.239.32.21.0: Flags [.],
win 512, length 0
12:43:08.961154 IP 192.168.0.127.10579 > 216.239.32.21.0: Flags [.],
win 512, length 0

Just try:
hping3 --flood target_host.

On Wed, Jun 17, 2015 at 12:34 PM, Maqbool Hashim  wrote:
> Hi,
>
> The destination host is sending an ACK+RST with the source port set to zero.  
> The destination IP is always one of the two hosts that are generating the SYN 
> packets with a destination port of 0.  The destination port however is hard 
> to match up to a source port in the original SYN packet due to the fact that 
> we don't have all the packets.
>
> It's actually going to be difficult to get the access and procedural sign off 
> etc. to run tcpdump on the machines involved.  What might be easier is to set 
> up a span port for the hosts access port on the switch and grab that via the 
> collector laptop I have.
>
> Thanks,
>
> MH
>
> 
> From: Marcin Cieslak 
> Sent: 17 June 2015 10:30
> To: Maqbool Hashim
> Cc: nanog@nanog.org
> Subject: Re: Fkiws with destination port 0 and TCP SYN flag set
>
> On Wed, 17 Jun 2015, Maqbool Hashim wrote:
>
>> It is always the same destination servers and in normal operations
>> these source and destination hosts do have a bunch of legitimate flows
>> between them.  I was leaning towards it being a reporting artifact,
>> but it's interesting that there are a whole set of Ack Reset packets
>> from the destination hosts with a source port of 0 also.
>
> So the destination host is sending ACK+RST with the *source* port
> set to zero, or the *destination* port?
>
>> Does this not indicate that it probably isn't a reporting artifact?
>
> I would just tcpdump on one of the source machines to find out.
>
> ~Marcin



--
Sincerely yours, Pavel Odintsov

Re: Fkiws with destination port 0 and TCP SYN flag set

[Pavel Odintsov]

Hello!

Just add --syn flag:

12:51:51.150085 IP 192.168.0.127.14628 > 216.239.34.21.0: Flags [S],
seq 680218921, win 512, length 0
12:51:51.150092 IP 192.168.0.127.14629 > 216.239.34.21.0: Flags [S],
seq 2073100941, win 512, length 0
12:51:51.150100 IP 192.168.0.127.14630 > 216.239.34.21.0: Flags [S],
seq 1003157405, win 512, length 0
12:51:51.150108 IP 192.168.0.127.14631 > 216.239.34.21.0: Flags [S],
seq 466773687, win 512, length 0
12:51:51.150115 IP 192.168.0.127.14632 > 216.239.34.21.0: Flags [S],
seq 338869897, win 512, length 0
12:51:51.150123 IP 192.168.0.127.14633 > 216.239.34.21.0: Flags [S],
seq 1513724122, win 512, length 0
12:51:51.150130 IP 192.168.0.127.14634 > 216.239.34.21.0: Flags [S],
seq 1971827612, win 512, length 0
12:51:51.150138 IP 192.168.0.127.14635 > 216.239.34.21.0: Flags [S],
seq 168197290, win 512, length 0
12:51:51.150146 IP 192.168.0.127.14636 > 216.239.34.21.0: Flags [S],
seq 1079714921, win 512, length 0
12:51:51.150153 IP 192.168.0.127.14637 > 216.239.34.21.0: Flags [S],
seq 1634213253, win 512, length 0
12:51:51.150161 IP 192.168.0.127.14638 > 216.239.34.21.0: Flags [S],
seq 1220755012, win 512, length 0
12:51:51.150168 IP 192.168.0.127.14639 > 216.239.34.21.0: Flags [S],
seq 351031228, win 512, length 0
12:51:51.150176 IP 192.168.0.127.14640 > 216.239.34.21.0: Flags [S],
seq 286599236, win 512, length 0
12:51:51.150184 IP 192.168.0.127.14641 > 216.239.34.21.0: Flags [S],
seq 125907752, win 512, length 0

 hping3 --flood --syn host.com

On Wed, Jun 17, 2015 at 12:50 PM, Maqbool Hashim  wrote:
> Hmm, no flags set in your output though?
>
> 
> From: Pavel Odintsov 
> Sent: 17 June 2015 10:44
> To: Maqbool Hashim
> Cc: Marcin Cieslak; nanog@nanog.org
> Subject: Re: Fkiws with destination port 0 and TCP SYN flag set
>
> Hello!
>
> Looks like it's silly hping3 flood:
>
> 12:43:08.961024 IP 192.168.0.127.10562 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961031 IP 192.168.0.127.10563 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961039 IP 192.168.0.127.10564 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961046 IP 192.168.0.127.10565 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961054 IP 192.168.0.127.10566 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961062 IP 192.168.0.127.10567 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961070 IP 192.168.0.127.10568 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961077 IP 192.168.0.127.10569 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961085 IP 192.168.0.127.10570 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961093 IP 192.168.0.127.10571 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961101 IP 192.168.0.127.10572 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961108 IP 192.168.0.127.10573 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961116 IP 192.168.0.127.10574 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961123 IP 192.168.0.127.10575 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961131 IP 192.168.0.127.10576 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961139 IP 192.168.0.127.10577 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961146 IP 192.168.0.127.10578 > 216.239.32.21.0: Flags [.],
> win 512, length 0
> 12:43:08.961154 IP 192.168.0.127.10579 > 216.239.32.21.0: Flags [.],
> win 512, length 0
>
> Just try:
> hping3 --flood target_host.
>
> On Wed, Jun 17, 2015 at 12:34 PM, Maqbool Hashim  wrote:
>> Hi,
>>
>> The destination host is sending an ACK+RST with the source port set to zero. 
>>  The destination IP is always one of the two hosts that are generating the 
>> SYN packets with a destination port of 0.  The destination port however is 
>> hard to match up to a source port in the original SYN packet due to the fact 
>> that we don't have all the packets.
>>
>> It's actually going to be difficult to get the access and procedural sign 
>> off etc. to run tcpdump on the machines involved.  What might be easier is 
>> to set up a span port for the hosts access port on the switch and grab that 
>> via the collector laptop I have.
>>
>> Thanks,
>>
>> MH
>>
>> 
>> From: Marcin Cieslak 
>> Sent: 17 June 2015 10:30
>> To: Maqbool Hashim
>> Cc: nanog@nanog.org
>> Subject: Re: Fkiws with destination port 0 and TCP SYN flag set
>>
>> On Wed, 17 Jun 2015, Maqbool Hashim wrote:
>>
>>> It is always the same destination servers and in normal operations
>>> these source and destination hosts do have a bunch of legitimate flows
>>> between them.  I was leaning towards it being a reporting artifact,
>>> but it's interesting that there are a whole set of Ack Reset packets
>>> from the destination hosts with a source port of 0 also.
>>
>> So the destination host is sending ACK+RST with the *source* port
>> set to zero, or the *dest

Re: Fkiws with destination port 0 and TCP SYN flag set

[Maqbool Hashim]

Agreed.  Might see if I can get netstat -antp output from the operators at some 
point though.

I will start with one of the hosts, looks like the whole flow capturing 
exercise for this LAN will need to be done using multiple laptops connected to 
the different access ports for the hosts.  No RSPAN support on these switches 
and no netflow :(


From: NANOG  on behalf of Roland Dobbins 

Sent: 17 June 2015 10:44
To: nanog@nanog.org
Subject: Re: Fkiws with destination port 0 and TCP SYN flag set

On 17 Jun 2015, at 11:34, Maqbool Hashim wrote:

> What might be easier is to set up a span port for the hosts access
> port on the switch and grab that via the collector laptop I have.

It's better to collect as much information you have without perturbing
the systems involved, anyways.

---
Roland Dobbins 

Re: Fkiws with destination port 0 and TCP SYN flag set

[Maqbool Hashim]

So, progressed to grabbing full packet dumps via monitor ports.  This confirmed 
that indeed the two hosts in question are generating traffic to the same four 
destinations with a destination port of zero.  Now that I have a full packet 
dump I see reset + ack packets coming back from source port 0 for every single 
one of the initial SYN packets.  Also it does look like a "scan" of some sort 
as the source port numbers are increasing by two or three every time and 
roughly 3-4 SYN packets per second being sent.  I am guessing this would be 
process binding to the next available TCP port on the source machine.

As far as I can tell to progress the analysis I need to move to doing forensics 
on the host itself.  It could be (as Pavel pointed out) be a utility like 
hping3 that someone has left running and forgotten about.  On the other hand it 
could be something more malicious I just don't know at the moment.  Any advice 
on this aspect would be great, unless considered off topic.

Finally I don't see how it could be, but be interested to hear peoples 
thoughts, no legitimate application could be generating this traffic could it?  
I mean I don't see what use an application could make of such a TCP 
conversation.  Discarding network analysis etc.  This machine runs a whole host 
of proprietary control system protocols, so haven't discarded the possibility 
totally- but I just can't see what an application protocol could find useful in 
a bunch of reset + ack packets being received from the destination hosts.

Regards,

MH


From: NANOG  on behalf of Maqbool 
Hashim 
Sent: 17 June 2015 10:54
To: Roland Dobbins; nanog@nanog.org
Subject: Re: Fkiws with destination port 0 and TCP SYN flag set

Agreed.  Might see if I can get netstat -antp output from the operators at some 
point though.

I will start with one of the hosts, looks like the whole flow capturing 
exercise for this LAN will need to be done using multiple laptops connected to 
the different access ports for the hosts.  No RSPAN support on these switches 
and no netflow :(


From: NANOG  on behalf of Roland Dobbins 

Sent: 17 June 2015 10:44
To: nanog@nanog.org
Subject: Re: Fkiws with destination port 0 and TCP SYN flag set

On 17 Jun 2015, at 11:34, Maqbool Hashim wrote:

> What might be easier is to set up a span port for the hosts access
> port on the switch and grab that via the collector laptop I have.

It's better to collect as much information you have without perturbing
the systems involved, anyways.

---
Roland Dobbins 

Re: Fkiws with destination port 0 and TCP SYN flag set

[Roland Dobbins]

On 17 Jun 2015, at 13:56, Maqbool Hashim wrote:


Any advice on this aspect would be great, unless considered off topic.


NANOG isn't really the right alias for this sort of thing.

TCP port-scanning on TCP/0 is a common reconnaissance mechanism.

Suggest you take this to a more appropriate alias like one of the 
bugtraq lists.


---
Roland Dobbins 

Re: Anycast provider for SMTP?

[Rafael Possamai]

https://www.google.com/intl/en/ipv6/statistics.html



On Mon, Jun 15, 2015 at 8:26 PM, Matt Palmer  wrote:

> On Mon, Jun 15, 2015 at 05:07:22PM -0700, Dave Taht wrote:
> > On Mon, Jun 15, 2015 at 5:00 PM, Randy Bush  wrote:
> > >> "What about IPv6? We have a plan! We plan to be dead before customers
> > >> demand IPv6".
> > >> I am pretty sure the authors are still alive(?).
> > >
> > > and customer demand for ipv6 still holds strong, right?
> >
> > Does seem to be on the uptick!
>
> It's certainly stronger than it has *ever* been before.
>
> - Matt
>
> --
> I am cow, hear me moo, I weigh twice as much as you. I'm a cow, eating
> grass, methane gas comes out my ass. I'm a cow, you are too; join us all!
> Type apt-get moo.
>
>

Re: Fkiws with destination port 0 and TCP SYN flag set

[Mark Milhollan]

On Wed, 17 Jun 2015, Maqbool Hashim wrote:

>Finally I don't see how it could be, but be interested to hear peoples 
>thoughts, no legitimate application could be generating this traffic 
>could it?  I mean I don't see what use an application could make of 
>such a TCP conversation.  Discarding network analysis etc.  This 
>machine runs a whole host of proprietary control system protocols, so 
>haven't discarded the possibility totally- but I just can't see what an 
>application protocol could find useful in a bunch of reset + ack 
>packets being received from the destination hosts.

Okay, setting aside the malicious possibilities, it may be that someone 
felt they needed something like ping but without the need for a raw 
socket.  I would worry about such code as there is usually sufficient 
proof the host is alive due to ongoing or new sessions.  Still, in 
process control it may be reasonable to check aliveness if, for example, 
there has been no normal activity for a seemingly small period of time, 
e.g., 50ms.  Such a test is only sufficient to prove that the TCP stack 
will respond, not the programs (which is where aliveness within the 
protocols is far more useful, classically PING and PONG).

Or perhaps a fence-post bug, e.g., a program is doing its own port 
selection with a max of 65535 where it accidentally uses max+1 which for 
a 16 bit unsigned value turns out to be 0, i.e., fixing the port number 
(setting it to the min value) after it is used rather than before.


/mark

Re: Fkiws with destination port 0 and TCP SYN flag set

[Maqbool Hashim]

Hi,

I'm investigating some of the protocols and will start looking at the processes 
on the machines.  Someone else rightly pointed out this getting off topic for 
NANOG, so thanks to everyone that responded.

Regards,

MH  


From: NANOG  on behalf of Mark Milhollan 

Sent: 17 June 2015 15:05
To: NANOG list
Subject: Re: Fkiws with destination port 0 and TCP SYN flag set

On Wed, 17 Jun 2015, Maqbool Hashim wrote:

>Finally I don't see how it could be, but be interested to hear peoples
>thoughts, no legitimate application could be generating this traffic
>could it?  I mean I don't see what use an application could make of
>such a TCP conversation.  Discarding network analysis etc.  This
>machine runs a whole host of proprietary control system protocols, so
>haven't discarded the possibility totally- but I just can't see what an
>application protocol could find useful in a bunch of reset + ack
>packets being received from the destination hosts.

Okay, setting aside the malicious possibilities, it may be that someone
felt they needed something like ping but without the need for a raw
socket.  I would worry about such code as there is usually sufficient
proof the host is alive due to ongoing or new sessions.  Still, in
process control it may be reasonable to check aliveness if, for example,
there has been no normal activity for a seemingly small period of time,
e.g., 50ms.  Such a test is only sufficient to prove that the TCP stack
will respond, not the programs (which is where aliveness within the
protocols is far more useful, classically PING and PONG).

Or perhaps a fence-post bug, e.g., a program is doing its own port
selection with a max of 65535 where it accidentally uses max+1 which for
a 16 bit unsigned value turns out to be 0, i.e., fixing the port number
(setting it to the min value) after it is used rather than before.


/mark

Google contact?

[Christopher Tyler]

Need some help.. Does anyone have an email contact at Google that they are 
willing to pass along?
All of our mowisp.net Apps for ISP accounts were disabled last night at about 
8-9PM without notice and we are now getting swamped with calls. Possibly 
several hundred users affected.

-- 
Christopher Tyler 
MTCRE/MTCNA/MTCTCE/MTCWE 
Total Highspeed Internet Services 
417.851.1107

RE: Google contact?

[Shawn L]

Google cancelled their ISP program as of the 8th of June.
 
Feel free to contact me off-list for more info.  They cancelled ours as well.


-Original Message-
From: "Christopher Tyler" 
Sent: Wednesday, June 17, 2015 9:28am
To: nanog@nanog.org
Subject: Google contact?



Need some help.. Does anyone have an email contact at Google that they are 
willing to pass along?
All of our mowisp.net Apps for ISP accounts were disabled last night at about 
8-9PM without notice and we are now getting swamped with calls. Possibly 
several hundred users affected.

-- 
Christopher Tyler 
MTCRE/MTCNA/MTCTCE/MTCWE 
Total Highspeed Internet Services 
417.851.1107

RE: Google contact?

[Matthew Black]

Hopefully, they sent you advance notice.

Google Apps for ISP EOL
https://productforums.google.com/forum/#!topic/apps/_zgHXEBjwKU


matthew black
california state university, long beach


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher Tyler
Sent: Wednesday, June 17, 2015 6:29 AM
To: nanog@nanog.org
Subject: Google contact?

Need some help.. Does anyone have an email contact at Google that they are 
willing to pass along?
All of our mowisp.net Apps for ISP accounts were disabled last night at about 
8-9PM without notice and we are now getting swamped with calls. Possibly 
several hundred users affected.

-- 
Christopher Tyler 
MTCRE/MTCNA/MTCTCE/MTCWE 
Total Highspeed Internet Services 
417.851.1107

Re: Google contact?

[Shawn L]

I'm replying on-list since it seems like a lot of people are in the same boat. 
 
Here's a summary of what happened to us.  Please feel free to jump in if you 
had a different experience, or have more information.
 
Google sent us a notice in December that as of June 8 they would be 
discontinuing the Google for ISPs program and that we had to find a different 
e-mail provider.  Unfortunately, they only sent this notice to the account that 
initially created the service, which was un-monitored.I have heard the same 
thing from others.  They did not include a notice about the discontinuation in 
their monthly billing, only in e-mail and only to the account that initiated 
the google service.
 
We actually found out about it some time in February.  I spoke with the Google 
contact listed in the e-mail and was told that they were indeed cancelling the 
service, but wasn't given a reason.  We also asked if it was possible to move 
to a different Google service, Google Apps for Business for example, but was 
told that it would be against their terms or service and would result in a 
cancellation of the service.
 
After a lot of research in Google's forums, it looked like a lot of other 
people were in the same boat we were.  We ended up talking with another e-mail 
provider and migrating all of our mail.  Several weeks ago we asked Google for 
an extension because the migration was taking longer than expected.  We were 
given until the 16th of June and told that no further extensions would be 
given.  I have spoken to one person who was given until the end of June.
 
Here is the original notice we received from google.  I hope this helps others 
in the same boat
 
 
December 10, 2014
 [ your-domain,com ]( http://baragatelephone.com )
 
 Subject: Notice of Non-Renewal of The Google Apps - ISP Partner Edition 
Agreement.
 
 Dear Administrator,
 Thank you for being a Google customer and for using Google Apps Partner 
Edition (collectively, "Partner Edition").
 As part of Google's integration plans, we have elected to discontinue 
providing the Partner Edition Services going forward. As provided in the 
Agreement between Google Inc. and [ your-domain.com ]( 
http://baragatelephone.com ), this letter serves as your formal notice that the 
Services will not be renewed, and our Agreement with you will terminate on June 
8, 2015.
 
 Any other Google services you have purchased (or resold, if applicable), in 
addition the Partner Edition product and services, will not be affected by this 
change. Please also note that this notice of non-renewal does not relieve you 
of any payment obligations you may have under the current Agreement and that 
you remain responsible for remitting any such owed payments in full by the 
applicable invoice due date for the Services.
 
 We have prepared an Administrator transition resource website ([ 
https://support.google.com/appstransition/go/admin ]( 
https://support.google.com/appstransition/go/admin )) and an End User resource 
website ([ https://support.google.com/appstransition ]( 
https://support.google.com/appstransition )) to assist you through the 
transition. This resource center presents some of the migration options 
available to you and provides instructions that you can share with your 
customers.
 
 We regret any inconvenience this may cause, and thank you again for your 
business. If you have any questions, please contact your Account Manager below.
 
 Account Manager:  John Coull
 Phone Number: [ 212- 565-3131 ]( tel:212-%20565-3131 )
 Email Address: [ joh...@google.com ]( mailto:joh...@google.com )
 
 Sincerely,
 Omid Kordestani
 Chief Business Officer
 
 
 


-Original Message-
From: "Marciano Lopes" 
Sent: Wednesday, June 17, 2015 11:48am
To: "Shawn L" 
Subject: Re: Google contact?




Hello Shawn!
 They cancelled ours as well.

What we can do?
 
Thanks!





 
 
Atenciosamente,
Marciano Lopes
GSURF
Fixo (48) 3254-8700 Ramal 6272
Móvel (48) 9125-5081
Atendimento 24h 0800-644-4833

2015-06-17 12:15 GMT-03:00 Shawn L <[ sha...@up.net ]( mailto:sha...@up.net )>:

 Google cancelled their ISP program as of the 8th of June.

 Feel free to contact me off-list for more info.  They cancelled ours as well.




 -Original Message-
 From: "Christopher Tyler" <[ ch...@totalhighspeed.net ]( 
mailto:ch...@totalhighspeed.net )>
 Sent: Wednesday, June 17, 2015 9:28am
 To: [ nanog@nanog.org ]( mailto:nanog@nanog.org )
 Subject: Google contact?



 Need some help.. Does anyone have an email contact at Google that they are 
willing to pass along?
 All of our [ mowisp.net ]( http://mowisp.net ) Apps for ISP accounts were 
disabled last night at about 8-9PM without notice and we are now getting 
swamped with calls. Possibly several hundred users affected.

 --
 Christopher Tyler
 MTCRE/MTCNA/MTCTCE/MTCWE
 Total Highspeed Internet Services
[ 417.851.1107 ]( tel:417.851.1107 )

Re: Google contact?

[Josh Luthman]

I was actually told July 6 or 9 in my email (which was delivered to that
unmonitored mail box like you).  I told customers July 1.  We lost it June
9.


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Wed, Jun 17, 2015 at 12:10 PM, Shawn L  wrote:

>
> I'm replying on-list since it seems like a lot of people are in the same
> boat.
>
> Here's a summary of what happened to us.  Please feel free to jump in if
> you had a different experience, or have more information.
>
> Google sent us a notice in December that as of June 8 they would be
> discontinuing the Google for ISPs program and that we had to find a
> different e-mail provider.  Unfortunately, they only sent this notice to
> the account that initially created the service, which was un-monitored.
> I have heard the same thing from others.  They did not include a notice
> about the discontinuation in their monthly billing, only in e-mail and only
> to the account that initiated the google service.
>
> We actually found out about it some time in February.  I spoke with the
> Google contact listed in the e-mail and was told that they were indeed
> cancelling the service, but wasn't given a reason.  We also asked if it was
> possible to move to a different Google service, Google Apps for Business
> for example, but was told that it would be against their terms or service
> and would result in a cancellation of the service.
>
> After a lot of research in Google's forums, it looked like a lot of other
> people were in the same boat we were.  We ended up talking with another
> e-mail provider and migrating all of our mail.  Several weeks ago we asked
> Google for an extension because the migration was taking longer than
> expected.  We were given until the 16th of June and told that no further
> extensions would be given.  I have spoken to one person who was given until
> the end of June.
>
> Here is the original notice we received from google.  I hope this helps
> others in the same boat
>
>
> December 10, 2014
>  [ your-domain,com ]( http://baragatelephone.com )
>
>  Subject: Notice of Non-Renewal of The Google Apps - ISP Partner Edition
> Agreement.
>
>  Dear Administrator,
>  Thank you for being a Google customer and for using Google Apps Partner
> Edition (collectively, "Partner Edition").
>  As part of Google's integration plans, we have elected to discontinue
> providing the Partner Edition Services going forward. As provided in the
> Agreement between Google Inc. and [ your-domain.com ](
> http://baragatelephone.com ), this letter serves as your formal notice
> that the Services will not be renewed, and our Agreement with you will
> terminate on June 8, 2015.
>
>  Any other Google services you have purchased (or resold, if applicable),
> in addition the Partner Edition product and services, will not be affected
> by this change. Please also note that this notice of non-renewal does not
> relieve you of any payment obligations you may have under the current
> Agreement and that you remain responsible for remitting any such owed
> payments in full by the applicable invoice due date for the Services.
>
>  We have prepared an Administrator transition resource website ([
> https://support.google.com/appstransition/go/admin ](
> https://support.google.com/appstransition/go/admin )) and an End User
> resource website ([ https://support.google.com/appstransition ](
> https://support.google.com/appstransition )) to assist you through the
> transition. This resource center presents some of the migration options
> available to you and provides instructions that you can share with your
> customers.
>
>  We regret any inconvenience this may cause, and thank you again for your
> business. If you have any questions, please contact your Account Manager
> below.
>
>  Account Manager:  John Coull
>  Phone Number: [ 212- 565-3131 ]( tel:212-%20565-3131 )
>  Email Address: [ joh...@google.com ]( mailto:joh...@google.com )
>
>  Sincerely,
>  Omid Kordestani
>  Chief Business Officer
>
>
>
>
>
> -Original Message-
> From: "Marciano Lopes" 
> Sent: Wednesday, June 17, 2015 11:48am
> To: "Shawn L" 
> Subject: Re: Google contact?
>
>
>
>
> Hello Shawn!
>  They cancelled ours as well.
>
> What we can do?
>
> Thanks!
>
>
>
>
>
>
>
> Atenciosamente,
> Marciano Lopes
> GSURF
> Fixo (48) 3254-8700 Ramal 6272
> Móvel (48) 9125-5081
> Atendimento 24h 0800-644-4833
>
> 2015-06-17 12:15 GMT-03:00 Shawn L <[ sha...@up.net ]( mailto:
> sha...@up.net )>:
>
>  Google cancelled their ISP program as of the 8th of June.
>
>  Feel free to contact me off-list for more info.  They cancelled ours as
> well.
>
>
>
>
>  -Original Message-
>  From: "Christopher Tyler" <[ ch...@totalhighspeed.net ]( mailto:
> ch...@totalhighspeed.net )>
>  Sent: Wednesday, June 17, 2015 9:28am
>  To: [ nanog@nanog.org ]( mailto:nanog@nanog.org )
>  Subject: Google contact?
>
>
>
>  Need some help.. Does anyone have an email contact at Google that th

Re: Google contact?

[Mike Hammett]

This seems to come up about once a month for quite some time on various lists. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

- Original Message -

From: "Shawn L"  
To: "marciano lopes"  
Cc: "nanog"  
Sent: Wednesday, June 17, 2015 11:10:24 AM 
Subject: Re: Google contact? 


I'm replying on-list since it seems like a lot of people are in the same boat. 

Here's a summary of what happened to us. Please feel free to jump in if you had 
a different experience, or have more information. 

Google sent us a notice in December that as of June 8 they would be 
discontinuing the Google for ISPs program and that we had to find a different 
e-mail provider. Unfortunately, they only sent this notice to the account that 
initially created the service, which was un-monitored. I have heard the same 
thing from others. They did not include a notice about the discontinuation in 
their monthly billing, only in e-mail and only to the account that initiated 
the google service. 

We actually found out about it some time in February. I spoke with the Google 
contact listed in the e-mail and was told that they were indeed cancelling the 
service, but wasn't given a reason. We also asked if it was possible to move to 
a different Google service, Google Apps for Business for example, but was told 
that it would be against their terms or service and would result in a 
cancellation of the service. 

After a lot of research in Google's forums, it looked like a lot of other 
people were in the same boat we were. We ended up talking with another e-mail 
provider and migrating all of our mail. Several weeks ago we asked Google for 
an extension because the migration was taking longer than expected. We were 
given until the 16th of June and told that no further extensions would be 
given. I have spoken to one person who was given until the end of June. 

Here is the original notice we received from google. I hope this helps others 
in the same boat 


December 10, 2014 
[ your-domain,com ]( http://baragatelephone.com ) 

Subject: Notice of Non-Renewal of The Google Apps - ISP Partner Edition 
Agreement. 

Dear Administrator, 
Thank you for being a Google customer and for using Google Apps Partner Edition 
(collectively, "Partner Edition"). 
As part of Google's integration plans, we have elected to discontinue providing 
the Partner Edition Services going forward. As provided in the Agreement 
between Google Inc. and [ your-domain.com ]( http://baragatelephone.com ), this 
letter serves as your formal notice that the Services will not be renewed, and 
our Agreement with you will terminate on June 8, 2015. 

Any other Google services you have purchased (or resold, if applicable), in 
addition the Partner Edition product and services, will not be affected by this 
change. Please also note that this notice of non-renewal does not relieve you 
of any payment obligations you may have under the current Agreement and that 
you remain responsible for remitting any such owed payments in full by the 
applicable invoice due date for the Services. 

We have prepared an Administrator transition resource website ([ 
https://support.google.com/appstransition/go/admin ]( 
https://support.google.com/appstransition/go/admin )) and an End User resource 
website ([ https://support.google.com/appstransition ]( 
https://support.google.com/appstransition )) to assist you through the 
transition. This resource center presents some of the migration options 
available to you and provides instructions that you can share with your 
customers. 

We regret any inconvenience this may cause, and thank you again for your 
business. If you have any questions, please contact your Account Manager below. 

Account Manager: John Coull 
Phone Number: [ 212- 565-3131 ]( tel:212-%20565-3131 ) 
Email Address: [ joh...@google.com ]( mailto:joh...@google.com ) 

Sincerely, 
Omid Kordestani 
Chief Business Officer 





-Original Message- 
From: "Marciano Lopes"  
Sent: Wednesday, June 17, 2015 11:48am 
To: "Shawn L"  
Subject: Re: Google contact? 




Hello Shawn! 
They cancelled ours as well. 

What we can do? 

Thanks! 







Atenciosamente, 
Marciano Lopes 
GSURF 
Fixo (48) 3254-8700 Ramal 6272 
Móvel (48) 9125-5081 
Atendimento 24h 0800-644-4833 

2015-06-17 12:15 GMT-03:00 Shawn L <[ sha...@up.net ]( mailto:sha...@up.net )>: 

Google cancelled their ISP program as of the 8th of June. 

Feel free to contact me off-list for more info. They cancelled ours as well. 




-Original Message- 
From: "Christopher Tyler" <[ ch...@totalhighspeed.net ]( 
mailto:ch...@totalhighspeed.net )> 
Sent: Wednesday, June 17, 2015 9:28am 
To: [ nanog@nanog.org ]( mailto:nanog@nanog.org ) 
Subject: Google contact? 



Need some help.. Does anyone have an email contact at Google that they are 
willing to pass along? 
All of our [ mowisp.net ]( http://mowisp.net ) Apps for ISP accounts were 
disabled last night at about 8-9PM without noti

Re: Anycast provider for SMTP?

[Ray Soucy]

Anycast is generally not well-suited for stateful connectivity (e.g. most
things TCP).  The use case for anycast is restricted to simple
challenge-response protocol design.

As such, you typically only see it leveraged for simple services (e.g. DNS,
NTP).

The reason for this, as you suspect, is you can never guarantee that the
path and thus the server will remain consistent across client connections.

Ideally you can leverage DNS to provide a response to a unicast resource
rather than trying to make the service itself anycast.  DNS can be anycast,
and DNS can provide different responses based on geographical location, but
these can happen independently or together.

As you still want failover, you might opt to announce the MX record with
the priorities reversed but still pointing to each server.  For example MX
10 server1, MX 20 server2 on one side, and MX 10 server2, MX 20 server1 on
the other.

Typically you would use a DNS load balancer rather than simple anycast DNS
to achieve this though.


On Mon, Jun 15, 2015 at 1:50 PM, Joe Hamelin  wrote:

> I have a mail system where there are two MX hosts, one in the US and one in
> Europe.  Both have a DNS MX record metric of 10 so a bastardized
> round-robin takes place.  This does not work so well when one site goes
> down.   My solution will be to place a load balancer in a hosting site
> (virtual, of course) and have it provide HA.  But what about HA for the
> LB?  At first glance anycasting would seem to be a great idea but there is
> a problem of broken sessions when routes change.
>
> Have any of you seen something like this work in the wild?
>
>
> --
> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

DMARC in education

[Matthew Black]

Looking at implementing DMARC for my institution. We currently have an SPF 
record and use DKIM to sign a small subset of messages. Rollout recommendations 
for DMARC suggest initially creating a "p=none" record to gather information on 
how a domain is being used. The RUA tag specifies a URI of where to send daily 
reports.

Trying to get an idea of how many reports to expect a day or two after the dust 
settles. Does anyone use an aggregator to process their feedback (RUA tag) 
and/or forensic reports (RUF tag)?

DMARC information.
https://dmarc.org/


See slide 38 of 93 at 
http://www.slideshare.net/kka7/fighting-email-abuse-with-dmarc?qid=5e90be27-3fc0-41ed-9d71-253978cc6a12&v=default&b=&from_search=2

Everyone's first DMARC record
V=DMARC1; p=none; rua=mailto:aggreg...@example.com;


Cheers!

matthew black
information technology services
california state university, long beach

Is it safe to use 240.0.0.0/4

[Luan Nguyen]

Is that safe to use internally? Anyone using it?
Just for NATTING on Cisco gears...

Re: Is it safe to use 240.0.0.0/4

[Ca By]

On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen  wrote:

> Is that safe to use internally? Anyone using it?
> Just for NATTING on Cisco gears...
>

most things, including most cisco gear, will not forward those Class E
packets or accept Class E as a valid address

If you have success, please report it to the list.

RE: Anycast provider for SMTP?

[Chuck Church]

Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ray Soucy
Sent: Wednesday, June 17, 2015 3:14 PM
To: Joe Hamelin
Cc: NANOG list
Subject: Re: Anycast provider for SMTP?


>As such, you typically only see it leveraged for simple services (e.g. DNS, 
>NTP).

I've been thinking about this for NTP.  Wouldn't you end up with constant 
corrections with NTP and Anycast?  Or is the assumption your anycasted NTP 
hosts are all peers of each other and extremely close in time to one another?  
That still wouldn't address the latency differences between the different hosts.

Chuck

RE: Is it safe to use 240.0.0.0/4

[Tony Wicks]

Use 100.64.0.0/10, this is the CGNAT reserved range.I would most definitely not 
recommend 240.0.0.0



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Luan Nguyen
Sent: Thursday, 18 June 2015 9:07 a.m.
To: nanog@nanog.org
Subject: Is it safe to use 240.0.0.0/4

Is that safe to use internally? Anyone using it?
Just for NATTING on Cisco gears...

Re: Is it safe to use 240.0.0.0/4

[Josh Luthman]

Probably fine to NAT it yourself until it is allocated and someone starts
using it.

Why not just use RFC1918 space?

https://www.google.com/fusiontables/DataSource?docid=1JEgabzMOJx1l25zHZK5wv4_Tn9KRsyDGgSq-M4g


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen  wrote:

> Is that safe to use internally? Anyone using it?
> Just for NATTING on Cisco gears...
>

Re: Is it safe to use 240.0.0.0/4

[Luan Nguyen]

Cisco IOS-XE Fails
ip add 241.1.1.1 255.255.255.0
Not a valid host address - 241.1.1.1
ip route 241.0.0.0 255.0.0.0 10.10.10.1
%Invalid destination prefix
XR-OS : fails
Can take the IP on a interface, but cant route it
IOS fails

we used up all the reserved ip blocks including the 169.254 and the
benchmark, and the 100.64/10 and ofcourse the RFC1918.
Lots of apps don't do ipv6 so we are finding interim solution...i guess
that's karma since doing so sort of anti-facilitating the use of ipv6 :)

On Wed, Jun 17, 2015 at 5:12 PM, Ca By  wrote:

> On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen  wrote:
>
> > Is that safe to use internally? Anyone using it?
> > Just for NATTING on Cisco gears...
> >
>
> most things, including most cisco gear, will not forward those Class E
> packets or accept Class E as a valid address
>
> If you have success, please report it to the list.
>

Re: Anycast provider for SMTP?

[Joe Abley]

On Jun 17, 2015, at 17:15, Chuck Church  wrote:

>> As such, you typically only see it leveraged for simple services (e.g. DNS, 
>> NTP).
>
> I've been thinking about this for NTP.  Wouldn't you end up with constant 
> corrections with NTP and Anycast?

I am not a time geek, but the general and consistent advice I have
heard from actual such geeks is, as you suspected, not to use anycast
to distribute NTP service.

I imagine that advice could be modified somewhat if you differentiate
between NTP as used within a mesh of well-synchronised clocks and NTP
as an occasional service for mobile clients that require only a loose
sense of now. The latter seems like availability might be more
important than stability over an extended period, so anycast might
make sense there.


Joe

Re: Is it safe to use 240.0.0.0/4

[Eduardo Schoedler]

And what about 0.0.0.0/8?

--
Eduardo Schoedler

2015-06-17 18:21 GMT-03:00 Luan Nguyen :

> Cisco IOS-XE Fails
> ip add 241.1.1.1 255.255.255.0
> Not a valid host address - 241.1.1.1
> ip route 241.0.0.0 255.0.0.0 10.10.10.1
> %Invalid destination prefix
> XR-OS : fails
> Can take the IP on a interface, but cant route it
> IOS fails
>
> we used up all the reserved ip blocks including the 169.254 and the
> benchmark, and the 100.64/10 and ofcourse the RFC1918.
> Lots of apps don't do ipv6 so we are finding interim solution...i guess
> that's karma since doing so sort of anti-facilitating the use of ipv6 :)
>
> On Wed, Jun 17, 2015 at 5:12 PM, Ca By  wrote:
>
> > On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen 
> wrote:
> >
> > > Is that safe to use internally? Anyone using it?
> > > Just for NATTING on Cisco gears...
> > >
> >
> > most things, including most cisco gear, will not forward those Class E
> > packets or accept Class E as a valid address
> >
> > If you have success, please report it to the list.
> >
>



-- 
Eduardo Schoedler

Re: Anycast provider for SMTP?

[Ray Soucy]

NTP might have been a bad example for the timing reasons.  One thing to
keep in mind with anycast is that unless there are problems the routes are
fairly stable and depending on how many servers you deploy and what route
visibility you have even different providers will often see the same
location as the closest path in terms of BGP.

I believe pool.ntp.org employs anycast to some extent, but I'm not sure
about that.  SNTP seems to to have a discovery component designed to work
well with anycast.

RFC 7094 has a good summary of all this.

In general, the consensus seems to be that anycast is better used for
discovery services rather than services themselves.





On Wed, Jun 17, 2015 at 5:12 PM, Chuck Church  wrote:

> Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ray Soucy
> Sent: Wednesday, June 17, 2015 3:14 PM
> To: Joe Hamelin
> Cc: NANOG list
> Subject: Re: Anycast provider for SMTP?
>
>
> >As such, you typically only see it leveraged for simple services (e.g.
> DNS, NTP).
>
> I've been thinking about this for NTP.  Wouldn't you end up with constant
> corrections with NTP and Anycast?  Or is the assumption your anycasted NTP
> hosts are all peers of each other and extremely close in time to one
> another?  That still wouldn't address the latency differences between the
> different hosts.
>
> Chuck
>
>


-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: Is it safe to use 240.0.0.0/4

[Ricky Beam]

On Wed, 17 Jun 2015 17:07:25 -0400, Luan Nguyen   
wrote:

Is that safe to use internally? Anyone using it?
Just for NATTING on Cisco gears...


As you've already figured out, Class E space is still restricted on Cisco  
gear.


I'll wait for Curran to pop up with various links to reasons why Class E  
was "abandoned" by ARIN. (short answer: too much broken crap thinks it's  
multicast!)

Re: DMARC in education

[Baldur Norddahl]

We use dmarcian.com to process the reports.

Regards

Baldur

Re: Is it safe to use 240.0.0.0/4

[Ray Soucy]

There is already more than enough address space allocated for NAT, you
don't need to start using random prefixes that may or may not be needed for
other purposes in the future.

For all we know, tomorrow someone could write an RFC requesting an address
reserved for local anycast DNS and it could be assigned from this block.

On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen  wrote:

> Is that safe to use internally? Anyone using it?
> Just for NATTING on Cisco gears...
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: Is it safe to use 240.0.0.0/4

[Tom Paseka via NANOG]

You'll find as well, a lot of hosts (eg, I know at least Windows XP)
won't forward to Class E destinations.

-Tom

On Wed, Jun 17, 2015 at 2:50 PM, Ray Soucy  wrote:
> There is already more than enough address space allocated for NAT, you
> don't need to start using random prefixes that may or may not be needed for
> other purposes in the future.
>
> For all we know, tomorrow someone could write an RFC requesting an address
> reserved for local anycast DNS and it could be assigned from this block.
>
> On Wed, Jun 17, 2015 at 5:07 PM, Luan Nguyen  wrote:
>
>> Is that safe to use internally? Anyone using it?
>> Just for NATTING on Cisco gears...
>>
>
>
>
> --
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
>
> T: 207-561-3526
> F: 207-561-3531
>
> MaineREN, Maine's Research and Education Network
> www.maineren.net

Re: Is it safe to use 240.0.0.0/4

[Job Snijders]

On Wed, Jun 17, 2015 at 05:07:25PM -0400, Luan Nguyen wrote:
> Is that safe to use [240.0.0.0/4] internally? Anyone using it?  Just
> for NATTING on Cisco gears...

On Wed, Jun 17, 2015 at 06:30:04PM -0300, Eduardo Schoedler wrote:
> And what about 0.0.0.0/8?

On both counts: NO. I always assume parties strive to deliver the best
service to their respective customers, IMHO this means avoiding IP space
which was not designated for a global purpose (yet).

Kind regards,

Job

Re: Is it safe to use 240.0.0.0/4

[Rafael Possamai]

Using CGNAT doesn't sound right either, although I haven't read the whole
thing, but it seems reasonable to use that block for CGNAT only.

https://tools.ietf.org/html/rfc1918


On Wed, Jun 17, 2015 at 4:13 PM, Tony Wicks  wrote:

> Use 100.64.0.0/10, this is the CGNAT reserved range.I would most
> definitely not recommend 240.0.0.0
>
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Luan Nguyen
> Sent: Thursday, 18 June 2015 9:07 a.m.
> To: nanog@nanog.org
> Subject: Is it safe to use 240.0.0.0/4
>
> Is that safe to use internally? Anyone using it?
> Just for NATTING on Cisco gears...
>
>

Re: DMARC in education

[Franck Martin via NANOG]

You have dmarcian, returnpath and agari to process reports.

https://dmarcian.com/dmarc-status/

Will give you an idea who send aggregate reports. To state the obvious,
they will send you a report only if you send them email.

Allow 24 to 48 hours to get your first reports, if you don't get any, check
your anti-spam filters and mail logs.

On Wed, Jun 17, 2015 at 2:49 PM, Baldur Norddahl 
wrote:

> We use dmarcian.com to process the reports.
>
> Regards
>
> Baldur
>

Re: Is it safe to use 240.0.0.0/4

[William Herrin]

On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam  wrote:
> I'll wait for Curran to pop up with various links to reasons why Class E was
> "abandoned" by ARIN. (short answer: too much broken crap thinks it's
> multicast!)

Hi Ricky,

You may be confused. ARIN never possessed class E; it's held in
reserve by IETF. As much as I enjoy a good ARIN bashing, they and John
Curran are quite faultless here.

IIRC, the short answer why it wasn't repurposed as additional unicast
addresses was that too much deployed gear has it hardcoded as
"reserved, future functionality unknown, do not use." Following an
instruction to repurpose 240/4 as unicast addresses, such gear would
not receive new firmware or obsolete out of use quickly enough to be
worth the effort.

Given how slowly IPv6 is deploying, this choice may prove to have been
shortsighted. Had IETF designated class-E as "reserved, future
unicast" in 2008 when the issue was debated and asked vendors to
update their software to expect 240/4 to be used as unicast addresses,
half the problem equipment would already have aged out and we could
all be debating whether to make them more RFC-1918 or hand them off to
the RIRs.

Regards,
Bill Herrin



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

Re: Is it safe to use 240.0.0.0/4

[Ca By]

On Wednesday, June 17, 2015, William Herrin  wrote:

> On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam  > wrote:
> > I'll wait for Curran to pop up with various links to reasons why Class E
> was
> > "abandoned" by ARIN. (short answer: too much broken crap thinks it's
> > multicast!)
>
> Hi Ricky,
>
> You may be confused. ARIN never possessed class E; it's held in
> reserve by IETF. As much as I enjoy a good ARIN bashing, they and John
> Curran are quite faultless here.
>
> IIRC, the short answer why it wasn't repurposed as additional unicast
> addresses was that too much deployed gear has it hardcoded as
> "reserved, future functionality unknown, do not use." Following an
> instruction to repurpose 240/4 as unicast addresses, such gear would
> not receive new firmware or obsolete out of use quickly enough to be
> worth the effort.
>
> Given how slowly IPv6 is deploying, this



Pardon me. But Apple has at least suggested y'all should be ready for
ipv6-only networks, not class E


http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-service-is-coming-soon-get-your-apps-ready/

http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv6-support-for-all-ios-9-apps/

And the source video which is worth watching from start to finish

https://developer.apple.com/videos/wwdc/2015/?id=719


choice may prove to have been
> shortsighted. Had IETF designated class-E as "reserved, future
> unicast" in 2008 when the issue was debated and asked vendors to
> update their software to expect 240/4 to be used as unicast addresses,
> half the problem equipment would already have aged out and we could
> all be debating whether to make them more RFC-1918 or hand them off to
> the RIRs.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com 
> b...@herrin.us 
> Owner, Dirtside Systems . Web: 
>

Re: Is it safe to use 240.0.0.0/4

[Mark Andrews]

In message 
, Ca By 
writes:
> On Wednesday, June 17, 2015, William Herrin  wrote:
> 
> > On Wed, Jun 17, 2015 at 5:38 PM, Ricky Beam  > > wrote:
> > > I'll wait for Curran to pop up with various links to reasons why Class E
> > was
> > > "abandoned" by ARIN. (short answer: too much broken crap thinks it's
> > > multicast!)
> >
> > Hi Ricky,
> >
> > You may be confused. ARIN never possessed class E; it's held in
> > reserve by IETF. As much as I enjoy a good ARIN bashing, they and John
> > Curran are quite faultless here.
> >
> > IIRC, the short answer why it wasn't repurposed as additional unicast
> > addresses was that too much deployed gear has it hardcoded as
> > "reserved, future functionality unknown, do not use." Following an
> > instruction to repurpose 240/4 as unicast addresses, such gear would
> > not receive new firmware or obsolete out of use quickly enough to be
> > worth the effort.
> >
> > Given how slowly IPv6 is deploying, this
> 
> 
> 
> Pardon me. But Apple has at least suggested y'all should be ready for
> ipv6-only networks, not class E
> 
> 
> http://arstechnica.com/apple/2015/06/apple-to-ios-devs-ipv6-only-cell-service-is-coming-soon-get-your-apps-ready/
> 
> http://www.internetsociety.org/deploy360/blog/2015/06/apple-will-require-ipv6-support-for-all-ios-9-apps/
> 
> And the source video which is worth watching from start to finish
> 
> https://developer.apple.com/videos/wwdc/2015/?id=719

Well the cell carriers are kind of forcing the issue here for iOS.
They want to go IPv6-only and Apple doesn't want to do 464XLAT last
I heard (haven't watched the video yet).  If all the apps can run
in a IPv6 only environment then there is only IPv4 literals in web
pages and tethered equipement to worry about so there is less presure
to implement 464XLAT.

Breaking pages with IPv4 literals may actually be a good thing at
this stage.  We are 20 years into the migration to IPv6.  15 years
of production IPv6 behind us.

Most tethered equipment can do IPv6.  The only hold outs there are
servers that they want to connect to are IPv6 only.  Forcing the
issue here would also be a good thing.

Additionally lots of big companies (FaceBook, Microsoft) are trying
to go IPv6 only internally as are data centers.

A number of wireline ISP are IPv6 only using DS-Lite to transport
IPv4.  MAP is a future IPv4 as a service on IPv6 contender.

> choice may prove to have been
> > shortsighted. Had IETF designated class-E as "reserved, future
> > unicast" in 2008 when the issue was debated and asked vendors to
> > update their software to expect 240/4 to be used as unicast addresses,
> > half the problem equipment would already have aged out and we could
> > all be debating whether to make them more RFC-1918 or hand them off to
> > the RIRs.
> >
> > Regards,
> > Bill Herrin
> >
> >
> >
> > --
> > William Herrin  her...@dirtside.com 
> > b...@herrin.us 
> > Owner, Dirtside Systems . Web: 
> >
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: DMARC in education

[John Levine]

In article 
 you 
write:
>Looking at implementing DMARC for my institution.

What problem do you expect this to solve?  This is a real question,
since you can be 100% sure that any DMARC policy will wreak havoc on
any of your users who use mailing lists like this one.  Academic
institutions tend to have a lot of list users.

>Trying to get an idea of how many reports to expect a day or two after the 
>dust settles. Does anyone
>use an aggregator to process their feedback (RUA tag) and/or forensic reports 
>(RUF tag)?

Aggregate reports, probably no more than 10 per day per domain.
Failure reports, depends on how much traffic your users and people
pretending to be your users send to China, since Netease in China and
Linkedin are the only providers that sends them, with the vast
majority from Netease.  The aggregate reports are interesting, the
failure reports are not.

There are some scripts on the dmarc.org site I wrote that parse the
reports and put the interesting bits into a mysql database.  I doubt
you'll need any more than that to see how much trouble a DMARC policy
would cause.

R's,
John

Re: Is it safe to use 240.0.0.0/4

[Damian Menscher via NANOG]

Not used in the sense you imagine, but I designed a hack where we hash IPv6
addresses into 224/3 (class D and E space) so backends that don't support
IPv6 can still be provided a pseudo-IP.  This accelerated support of IPv6
across all Google services without needing to wait for each individual
backend to provide support.

See
https://www.nanog.org/meetings/nanog50/presentations/Wednesday/NANOG50.Talk41.colitti-IPv6%20transition%20experiences.pdf
slide 4 for a description, or
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/net/InetAddresses.html
for open-sourced code.

There may be other uses for IPs beyond routing.

Damian

On Wed, Jun 17, 2015 at 2:07 PM, Luan Nguyen  wrote:

> Is that safe to use internally? Anyone using it?
> Just for NATTING on Cisco gears...
>

Re: Is it safe to use 240.0.0.0/4

[Ricky Beam]

On Wed, 17 Jun 2015 18:38:32 -0400, William Herrin  wrote:

You may be confused. ARIN never possessed class E; it's held in
reserve by IETF. As much as I enjoy a good ARIN bashing, they and John
Curran are quite faultless here.


Quote-unquote, as in they didn't even bother *even proposing* to use Class  
E space. The reasons were numerous, btw. (hardcoded restrictions,  
erroneous classification as multicast, not worth the effort, etc.)



Given how slowly IPv6 is deploying, this choice may prove to have been
shortsighted.


I doubt it. As you said, there is A LOT of crap out there that would have  
to be updated. Pulling a number out of the air, I'd guess *most* in-use  
devices would NEVER see such an update. Even from companies that do still  
exist. (Sadly, those are also devices that aren't going to see IPv6,  
either.)

OPM Data Breach - Whitehouse Petition - Help Wanted

[Ronald F. Guilmette]

My apologies in advance to any here who might feel that this is off
topic... I don't personally believe that it is.  Frankly, I don't
know of that many mailing lists where the subscribers are likely to
care as much about network security (and/or the lack thereof) as the
membership of this list does.

By now, most of you will have read about the massive federal data breach
at the U.S. Government's Office of Personnel Management (OPM), and also
the fact that (by OPM's own preliminary estimates) this massive data breach
affects at least four million federal government employees... but perhaps
as many as 14 million current and former employees.  However as this
story is still evolving, even as we speak, you may perhaps not be familiar
with the following additional important facts that have just come out:

*)  In addition to ordinary government personel records, including
the usual kinds of frequently-hacked personal information (e.g.
social security numbers), an as-yet undetermined number of highly
detailed 127-page government security clearance forms (SF86)
containing vast and intimate details of virtually every aspect
of the lives of essentially EVERYONE who has applied for or been
granted a government security clearance at any time within THE
PAST 30 YEARS have also been hacked/leaked.

(Experts seem to agree that this security clearance data constitutes
and absolute gold mine and treasure trove of information for foreign
intelligence services, opening up vast possibilities for phishing,
blackmail, and on and on.)

*)  The Director of the Office of Personnel Management, Ms. Katherine
Archueta was warned, repeatedly, and over several years, by her
own department's Inspector General (IG) that many of OPM's systems
were insecure and should be taken out of service.  Nontheless, as
reveled during congressional testimony yesterday, she overruled
and ignored this advice and kept the systems online.

Given the above facts, I've just started a new Whitehouse Petition, asking
that the director of OPM, Ms. Archueta, be fired for gross incompetence.
I _do_ understand that the likelihood of anyone ever getting fired for
incompetence anywhere within the Washington D.C. Beltway is very much of
a long shot, based on history, but I nontheless feel that as a U.S.
citizen and taxpayer, I at least want to make my opinion of this matter
known to The Powers That Be.

I *really* would like some help from members of this list on this endeavor.
In particular, if you agree, I'd appreciate it if you would sign my petition,
and, whether you agree or not, I sure would appreciate it if you would all
share the following URL widely:

https://petitions.whitehouse.gov//petition/immediately-fire-office-personnel-managements-director-katherine-archueta-gross-incompetence

Note that Whitehouse petitions do not even get properly or completely
published on the Whitehouse web site until such time as they receive at
least 150 signatures.  I am hoping that members of this (NANOG) mailing
list will help me to get past that threshold.

Thanks for your attention.


Regards,
rfg

Re: Is it safe to use 240.0.0.0/4

[Ca By]

On Wednesday, June 17, 2015, Ricky Beam  wrote:

> On Wed, 17 Jun 2015 18:38:32 -0400, William Herrin  wrote:
>
>> You may be confused. ARIN never possessed class E; it's held in
>> reserve by IETF. As much as I enjoy a good ARIN bashing, they and John
>> Curran are quite faultless here.
>>
>
> Quote-unquote, as in they didn't even bother *even proposing* to use Class
> E space. The reasons were numerous, btw. (hardcoded restrictions, erroneous
> classification as multicast, not worth the effort, etc.)


 https://tools.ietf.org/html/draft-wilson-class-e-02

Proposed and denied. Please stop this line and spend your efforts on ipv6


>  Given how slowly IPv6 is deploying, this choice may prove to have been
>> shortsighted.
>>
>
> I doubt it. As you said, there is A LOT of crap out there that would have
> to be updated. Pulling a number out of the air, I'd guess *most* in-use
> devices would NEVER see such an update. Even from companies that do still
> exist. (Sadly, those are also devices that aren't going to see IPv6,
> either.)
>

Re: OPM Data Breach - Whitehouse Petition - Help Wanted

[Harry Hoffman]

I think it would be great if you were to include some source links in
your petition/email so that folks unaware of the specifics can educate
themselves in a non-partisan and factual manner.

Just my $0.02.

Cheers,
Harry


On 6/17/15 8:54 PM, Ronald F. Guilmette wrote:
> My apologies in advance to any here who might feel that this is off
> topic... I don't personally believe that it is.  Frankly, I don't
> know of that many mailing lists where the subscribers are likely to
> care as much about network security (and/or the lack thereof) as the
> membership of this list does.
>
> By now, most of you will have read about the massive federal data breach
> at the U.S. Government's Office of Personnel Management (OPM), and also
> the fact that (by OPM's own preliminary estimates) this massive data breach
> affects at least four million federal government employees... but perhaps
> as many as 14 million current and former employees.  However as this
> story is still evolving, even as we speak, you may perhaps not be familiar
> with the following additional important facts that have just come out:
>
> *)  In addition to ordinary government personel records, including
>   the usual kinds of frequently-hacked personal information (e.g.
>   social security numbers), an as-yet undetermined number of highly
>   detailed 127-page government security clearance forms (SF86)
>   containing vast and intimate details of virtually every aspect
>   of the lives of essentially EVERYONE who has applied for or been
>   granted a government security clearance at any time within THE
>   PAST 30 YEARS have also been hacked/leaked.
>
>   (Experts seem to agree that this security clearance data constitutes
>   and absolute gold mine and treasure trove of information for foreign
>   intelligence services, opening up vast possibilities for phishing,
>   blackmail, and on and on.)
>
> *)The Director of the Office of Personnel Management, Ms. 
> Katherine
>   Archueta was warned, repeatedly, and over several years, by her
>   own department's Inspector General (IG) that many of OPM's systems
>   were insecure and should be taken out of service.  Nontheless, as
>   reveled during congressional testimony yesterday, she overruled
>   and ignored this advice and kept the systems online.
>
> Given the above facts, I've just started a new Whitehouse Petition, asking
> that the director of OPM, Ms. Archueta, be fired for gross incompetence.
> I _do_ understand that the likelihood of anyone ever getting fired for
> incompetence anywhere within the Washington D.C. Beltway is very much of
> a long shot, based on history, but I nontheless feel that as a U.S.
> citizen and taxpayer, I at least want to make my opinion of this matter
> known to The Powers That Be.
>
> I *really* would like some help from members of this list on this endeavor.
> In particular, if you agree, I'd appreciate it if you would sign my petition,
> and, whether you agree or not, I sure would appreciate it if you would all
> share the following URL widely:
>
> https://petitions.whitehouse.gov//petition/immediately-fire-office-personnel-managements-director-katherine-archueta-gross-incompetence
>
> Note that Whitehouse petitions do not even get properly or completely
> published on the Whitehouse web site until such time as they receive at
> least 150 signatures.  I am hoping that members of this (NANOG) mailing
> list will help me to get past that threshold.
>
> Thanks for your attention.
>
>
> Regards,
> rfg

Re: OPM Data Breach - Whitehouse Petition - Help Wanted

[Tyler Mills]

This is the government... you have to put on your bizarro-economics and
bizarro-ethics glasses for the State to make sense.

It does not operate like a market.  Failure results in people being
shuffled around, and larger budgets. Failure justifies more control and
power.  People get taken down for political reasons, not based on a lack of
ability or lack of virtue.

I would hope this measure succeeds and to see something meaningful come out
of it, I just don't see it happening.



On Wed, Jun 17, 2015 at 8:56 PM Ronald F. Guilmette 
wrote:

>
> My apologies in advance to any here who might feel that this is off
> topic... I don't personally believe that it is.  Frankly, I don't
> know of that many mailing lists where the subscribers are likely to
> care as much about network security (and/or the lack thereof) as the
> membership of this list does.
>
> By now, most of you will have read about the massive federal data breach
> at the U.S. Government's Office of Personnel Management (OPM), and also
> the fact that (by OPM's own preliminary estimates) this massive data breach
> affects at least four million federal government employees... but perhaps
> as many as 14 million current and former employees.  However as this
> story is still evolving, even as we speak, you may perhaps not be familiar
> with the following additional important facts that have just come out:
>
> *)  In addition to ordinary government personel records, including
> the usual kinds of frequently-hacked personal information (e.g.
> social security numbers), an as-yet undetermined number of highly
> detailed 127-page government security clearance forms (SF86)
> containing vast and intimate details of virtually every aspect
> of the lives of essentially EVERYONE who has applied for or been
> granted a government security clearance at any time within THE
> PAST 30 YEARS have also been hacked/leaked.
>
> (Experts seem to agree that this security clearance data
> constitutes
> and absolute gold mine and treasure trove of information for
> foreign
> intelligence services, opening up vast possibilities for phishing,
> blackmail, and on and on.)
>
> *)  The Director of the Office of Personnel Management, Ms. Katherine
> Archueta was warned, repeatedly, and over several years, by her
> own department's Inspector General (IG) that many of OPM's systems
> were insecure and should be taken out of service.  Nontheless, as
> reveled during congressional testimony yesterday, she overruled
> and ignored this advice and kept the systems online.
>
> Given the above facts, I've just started a new Whitehouse Petition, asking
> that the director of OPM, Ms. Archueta, be fired for gross incompetence.
> I _do_ understand that the likelihood of anyone ever getting fired for
> incompetence anywhere within the Washington D.C. Beltway is very much of
> a long shot, based on history, but I nontheless feel that as a U.S.
> citizen and taxpayer, I at least want to make my opinion of this matter
> known to The Powers That Be.
>
> I *really* would like some help from members of this list on this endeavor.
> In particular, if you agree, I'd appreciate it if you would sign my
> petition,
> and, whether you agree or not, I sure would appreciate it if you would all
> share the following URL widely:
>
>
> https://petitions.whitehouse.gov//petition/immediately-fire-office-personnel-managements-director-katherine-archueta-gross-incompetence
>
> Note that Whitehouse petitions do not even get properly or completely
> published on the Whitehouse web site until such time as they receive at
> least 150 signatures.  I am hoping that members of this (NANOG) mailing
> list will help me to get past that threshold.
>
> Thanks for your attention.
>
>
> Regards,
> rfg
>
-- 
Tyler W. Mills
Infrastructure and Network Engineer
Atlanta,  GA.

Re: Is it safe to use 240.0.0.0/4

[Jonas Björk]

>> Given how slowly IPv6 is deploying, this choice may prove to have been
>> shortsighted.
> 
> I doubt it. As you said, there is A LOT of crap out there that would have to 
> be updated. Pulling a number out of the air, I'd guess *most* in-use devices 
> would NEVER see such an update. Even from companies that do still exist. 
> (Sadly, those are also devices that aren't going to see IPv6, either.) 

Most stuff out there do only care about that its subnet mask OR's up correctly 
with its ip and gw. Poof, there did 99.9 per cent of all devices get excluded. 
Most stuff that do use and/or misuse this freightening block of darkest 
cyberspace are either high end network equipment (who drop) or some end 
users/mcast sender which are behind NAT anyway.

I believe it's a great idea. Let's at least try it out, like an alpha-test. We 
choose a temporary /8 (easy to remember) and divide it into /16s or less, 
depending on how many interested candidates we are able to raise. After being 
approved by IANA we begin advertising our new prefixes for a finite amount of 
time. If the world ends, or is about to, we stop.

I believe we would bump into minor caveats but ISP's are beginning to NAT their 
end customers due to the lack of free ips and I wouldn't want to live in a 
world where that was the norm. This madness has to stop and v6 won't salvate us 
for yet another total sonar eclipse or three.

Let us at least try it out - if it goes well we have bought us some time. If 
not, revert.
Thank you for listening.

br /Mr Bjork

Re: DMARC in education

[Lyndon Nerenberg]

> What problem do you expect this to solve?  This is a real question,
> since you can be 100% sure that any DMARC policy will wreak havoc on
> any of your users who use mailing lists like this one.

*Any* mailing list.

Please help stamp out this abomination by refusing to capitulate to its insane 
desire to pretend the last three+ decades of email functionality never existed.

--lyndon



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: OPM Data Breach - Whitehouse Petition - Help Wanted

[Scott Weeks]

--- r...@tristatelogic.com wrote:
From: "Ronald F. Guilmette" 

*)  The Director of the Office of Personnel Management, Ms. Katherine
Archueta was warned, repeatedly, and over several years, by her
own department's Inspector General (IG) that many of OPM's systems
were insecure and should be taken out of service.  Nontheless, as
reveled during congressional testimony yesterday, she overruled
and ignored this advice and kept the systems online.
---


>From personal experience (at a different level) this 
is SOP, unfortunately.  They just don't understand the
importance until catastrophic failure.

scott

Re: Is it safe to use 240.0.0.0/4

[Ca By]

On Wednesday, June 17, 2015, Jonas Björk  wrote:

>
> >> Given how slowly IPv6 is deploying, this choice may prove to have been
> >> shortsighted.
> >
> > I doubt it. As you said, there is A LOT of crap out there that would
> have to be updated. Pulling a number out of the air, I'd guess *most*
> in-use devices would NEVER see such an update. Even from companies that do
> still exist. (Sadly, those are also devices that aren't going to see IPv6,
> either.)
>
> Most stuff out there do only care about that its subnet mask OR's up
> correctly with its ip and gw. Poof, there did 99.9 per cent of all devices
> get excluded. Most stuff that


Pretty sure this is wrong.


> do use and/or misuse this freightening block of darkest cyberspace are
> either high end network equipment (who drop) or some end users/mcast sender
> which are behind NAT anyway.
>
> I believe it's a great idea. Let's at least try it out, like an
> alpha-test. We choose a temporary /8 (easy to remember) and divide it into
> /16s or less, depending on how many interested candidates we are able to
> raise. After being approved by IANA we begin advertising our new prefixes
> for a finite amount of time. If the world ends, or is about to, we stop.
>
> I believe we would bump into minor caveats but ISP's are beginning to NAT
> their end customers due to the lack of free ips and I wouldn't want to live
> in a world where that was the norm. This madness has to stop and v6 won't
> salvate us for yet another total sonar eclipse or three.
>
>
Definately wrong. There are many networks larger and smaller than yours
that run ipv6-only (ds-lite, 464xlat, whatever facebook does in their dc).

You are wasting time and money.

Let us at least try it out - if it goes well we have bought us some time.
> If not, revert.
> Thank you for listening.
>
> br /Mr Bjork

Re: Is it safe to use 240.0.0.0/4

[Joe Provo]

No, we examined this back in 2007. See your favorite cache site
for http://puck.nether.net/mailman/listinfo/240-e 


-- 
RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG

Re: Is it safe to use 240.0.0.0/4

[John Levine]

>IIRC, the short answer why it wasn't repurposed as additional unicast
>addresses was that too much deployed gear has it hardcoded as
>"reserved, future functionality unknown, do not use." Following an
>instruction to repurpose 240/4 as unicast addresses, such gear would
>not receive new firmware or obsolete out of use quickly enough to be
>worth the effort.

More to the point, the amount of work required to fix all the existing
equipment to handle 240/4 would not be a lot less than the work
required to get it to handle IPv6, and it would only have pushed the
IPv4 exhaustion out a few years.  It was entirely reasonable to
conclude that it would not have been a good use of anyone's time or
money.

Look at the bright side: you can use the money you didn't spend on
240/4 upgrades to buy slightly used IPv4 space on the grey market
or CGN equipment.

R's,
John

Re: Is it safe to use 240.0.0.0/4

[Josh Luthman]

How many devices need IPs? Is there a reason ARIN can't be used?

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Jun 17, 2015 10:18 PM, "John Levine"  wrote:

> >IIRC, the short answer why it wasn't repurposed as additional unicast
> >addresses was that too much deployed gear has it hardcoded as
> >"reserved, future functionality unknown, do not use." Following an
> >instruction to repurpose 240/4 as unicast addresses, such gear would
> >not receive new firmware or obsolete out of use quickly enough to be
> >worth the effort.
>
> More to the point, the amount of work required to fix all the existing
> equipment to handle 240/4 would not be a lot less than the work
> required to get it to handle IPv6, and it would only have pushed the
> IPv4 exhaustion out a few years.  It was entirely reasonable to
> conclude that it would not have been a good use of anyone's time or
> money.
>
> Look at the bright side: you can use the money you didn't spend on
> 240/4 upgrades to buy slightly used IPv4 space on the grey market
> or CGN equipment.
>
> R's,
> John
>

Re: OPM Data Breach - Whitehouse Petition - Help Wanted

[Ronald F. Guilmette]

In message 
Tyler Mills  wrote:

>This is the government... you have to put on your bizarro-economics and
>bizarro-ethics glasses for the State to make sense.
>
>It does not operate like a market.  Failure results in people being
>shuffled around, and larger budgets. Failure justifies more control and
>power.  People get taken down for political reasons, not based on a lack of
>ability or lack of virtue.
>
>I would hope this measure succeeds and to see something meaningful come out
>of it, I just don't see it happening.

Thanks for your support.

And yes, I agree that most probably nothing will come of this, but it
is worth a try.

Consider this, if even just one out of every forty (1/40) of the affected
4+ million (now hopefully pissed off) federal workers signs this petition
then it will get past the 100,000 signature point and then the Whitehouse
will HAVE to respond to it.

Of course, even in that case, the WH might very well just put off their
response, you know, until that proverbial "cold day in hell"... just as
they have done, and continue to do, with the "Pardon Snowden" petition...
however as it that case, their mere lack of response... basically
ignoring their own rules which they made for themselves relating to
these petitions... would itself call more attention to their utter
failure, not only to prevent such breaches, but to even deal with
them in a sensible way afterwards.  (If this utterly unqualified
ethnic-checkbox woman had done this in the private sector, there's
no doubt that her ass would be out the door already.  As far as I have
been able to tell in my limited research, she never managed _anything_
in her life before being named as the head of OPM... not even a Denny's...
with the only possible exception being that she may have managed some
portion of the President's re-election campaign.)


Regards,
rfg


P.S.  I just learned that the story on this breach is even worse than
I already thought it was when I started the petition.  From ArsTechnica:

http://arstechnica.com/security/2015/06/encryption-would-not-have-helped-at-opm-says-dhs-official/

  ...
  A consultant who did some work with a company contracted by OPM to
  manage personnel records for a number of agencies told Ars that he
  found the Unix systems administrator for the project "was in
  Argentina and his co-worker was physically located in the [People's
  Republic of China]. Both had direct access to every row of data in
  every database: they were root. Another team that worked with these
  databases had at its head two team members with PRC passports. I
  know that because I challenged them personally and revoked their
  privileges. From my perspective, OPM compromised this information
  more than three years ago and my take on the current breach is
  'so what's new?'"

Un-bleeping believable!

There's nothing else that I can say about the quote above... at least
nothing else that I can say in polite company.

Re: Is it safe to use 240.0.0.0/4

[Ricky Beam]

On Wed, 17 Jun 2015 21:17:53 -0400, Ca By  wrote:

 https://tools.ietf.org/html/draft-wilson-class-e-02

Proposed and denied. Please stop this line and spend your efforts on ipv6


By APNIC. Cisco did, too, btw. And they weren't first, either. Nor is this  
going to be the last time someone suggests it.


To paraphrase Curran (since he's not popping by to say it), it's a lot of  
work that ultimately yields a small amount of space that's STILL going to  
run out. 16 /8's won't fix the problem.


Just deploy IPv6 already. Sure, there's plenty to complain about -- and we  
do complain! -- but it's what we have.


--Ricky

Re: OPM Data Breach - Whitehouse Petition - Help Wanted

[Ronald F. Guilmette]

Harry Hoffman hhoffman at ip-solutions.net wrote:

>I think it would be great if you were to include some source links in
>your petition/email so that folks unaware of the specifics can educate
>themselves in a non-partisan and factual manner.

Well, as regards to the petition itself, I can't because now it is
cast in stone and can't be edited, I think, which is too bad, because
I slightly misspelled the lady's name.  It is Katherine Archuleta,
not Katherine Archueta. :-(

But more to the point, they only give you a VERY limited number of
characters to state what your petition is asking for, so there's
really not room for much in the way of links within the petition
itself.

But elsewise, I'll give a few good links here, but really if you just
go to Google News and search for "OPM breach" you will find one hell
of a lot of VERY fresh news reports.

===
Fed Agency blames giant hack on 'neglected' security systems

http://www.usnews.com/news/politics/articles/2015/06/16/cybertheft-of-personnel-info-rips-hole-in-espionage-defenses

(Executive Summary: 4.2 mellion federal personel records stolen - OPM was
warned, repeatedly, FOR YEARS that systems were insecure and didn't do squat.)
===
Military clearance OPM data breach 'absolute calamity'

http://www.navytimes.com/story/military/2015/06/17/sf-86-security-clearance-breach-troops-affected-opm/28866125/

(Executive Summary:  Literally MILLIONS of detailed security clearance files
were taken... quote: "everyone's".)
===
OPM Hack Probe Hindered Because Digital Trail Has Been Erased, US Official Says

http://abcnews.go.com/US/opm-hack-probe-hindered-digital-trail-erased-us/story?id=31784335

(Executive Summary:  They don't know how long this lasted or even what
really happened because they over-write their log files every 60 days)
===
Will anyone at OPM be fired for not preventing this catastrophic mega-hack by 
China?

http://hotair.com/archives/2015/06/16/will-anyone-at-opm-be-fired-for-not-preventing-this-catastrophic-mega-hack-by-china/

Nope!  In fact, Whitehouse has already come out expressing confidence in
the OPM Director, Katherine Archuleta:

http://thehill.com/policy/cybersecurity/245294-obama-has-confidence-in-opm-director-despite-hack
===
Catching Up on the OPM Breach - Krebs On Security

http://krebsonsecurity.com/2015/06/catching-up-on-the-opm-breach/

(Detailed timeline of the MANY screw-ups)
===

And last but by no means least, we have ArsTechnica's most recent contribution
to the news coverage, it which the following UNBELIEVEABLE insanity is revealed:

Encryption would not have helped" at OPM, says DHS official
http://arstechnica.com/security/2015/06/encryption-would-not-have-helped-at-opm-says-dhs-official/

  ...
  A consultant who did some work with a company contracted by OPM to
  manage personnel records for a number of agencies told Ars that he
  found the Unix systems administrator for the project "was in
  Argentina and his co-worker was physically located in the [People's
  Republic of China]. Both had direct access to every row of data in
  every database: they were root. Another team that worked with these
  databases had at its head two team members with PRC passports. I
  know that because I challenged them personally and revoked their
  privileges. From my perspective, OPM compromised this information
  more than three years ago and my take on the current breach is
  'so what's new?'"

Yea.  Right.  If you are trying to keep foreign nationals out of your
"secure" system, then encryption quite certainly WILL NOT HELP if you
have already given them root.


Regards,
rfg


P.S.  Regadless of your politics or what you think of Snowden, THIS INCIDENT
is VASTLY WORSE that any leak that Snowden participated in.  At least he and
the reporters he worked with tried to exercise some discretion, and did not
leak any personal details about any specific U.S. government employees.  In
the case of this massive OPM hack however, the incompetents in charge of
OPM gave unknown foreign enemies EVERYTHING... enough data and personal dirt
on millions of federal employees... including active service members and
intelligence operatives... to allow them, our enemies, to engage in virtually
unlimited blackmailing and spear-phishing of our people until the Second
Coming.

For those who were worriedly waiting for the much-predicted "Digital Pearl
Harbor" attack on this country... well...  you don't have to fret about
THAT anymore, because this is it.  It's already