Internet2 Network Security SIG

[gcbrowni <>]

Yeah, I think we can work up that list. Adair, does that fit?

Not to pile on too much, but we’re even being UDP port 0 attacks in the analysis we’re doing in Deepfield Defender.  Much like 1918, etc, UDP port 0 is something that we should never see since its invalid. We’ll can that on the potential list also. I don’t want to go too far down that path, yet, but "that’s invalid" should be an easy call, especially since we see it in the wild. 

-G

On Jan 7, 2019, at 1:32 PM, David Farmer <> wrote:

Yes, please add the other stuff.

For IPv4, RFC1918 (Private-Use), RFC6598 (Shared Address Space), RFC3927 (Link-Local), RFC5737 (Documentation), 240.0.0.0/4 Reserved (Class E), 127.0.0.0/8 Loopback, 0.0.0.0/8 

For IPv6, RFC4193 (ULA), RFC3849  (Documentation), RFC6052 (Well-Known local NAT64), RFC8215 (other local NAT64), RFC6666 (Discard Prefix)

On Mon, Jan 7, 2019 at 11:01 AM gcbrowni <> wrote:

Well, unless we change the scope.

Let’s do 1918 and other "well known" bad source addresses. We can worry about "unassigned space" later.

How's that sound?


> On Jan 7, 2019, at 11:59 AM, Adair Thaxton <> wrote:
>
> I believe that only RFC1918 space is in scope for now.  Baby steps!
>
> Adair
>
>
> On 1/7/19 11:58 AM, Michael H Lambert wrote:
>> I fully agree with blocking RFC1918 addresses.  There are lots of other "static" bogon ranges, too, in both modern and legacy IP.  These include documentation and IANA-reserved addresses.  How aggressive should Internet2 (or connectors) be in blocking these in addition to RFC1918?
>>
>> Michael
>>
>>> On 7 Jan 2019, at 11:43, Brad Fleming <> wrote:
>>>
>>> I’m assuming RFC1918 IPs as the source, correct? Regardless of source or destination address I’m good with it. We shouldn’t be leaking that junk, if we are something is broken, and I don’t expect Internet2 or the greater community to deal with our failures. A publicly viewable counter on the firewall filter term could be useful; I could make one of our junior network team check the I2 counter every month to verify we don’t have an internal issue. I’d be fine if that instrumentation wasn’t added until later if I2 staff would like to move quickly on deploying filters but also want to gather more input from the community on exposing FW filter counters in this manner.
>>> --
>>> Brad Fleming
>>> Assistant Director for Technology
>>> Kansas Research and Education Network
>>>
>>>> On Jan 7, 2019, at 10:13 AM, Adair Thaxton <> wrote:
>>>>
>>>> I trust everyone had a nice break, and hasn't been driven up the wall by
>>>> bored children yet.  Our three-year-old reached the "why?" stage just in
>>>> time for break, so if you're still sane, I envy you!
>>>>
>>>>
>>>> - Internet2 is considering blocking all RFC1918 space at ingress links.
>>>> We do not expect this to affect cloud tunnel traffic, or any legitimate
>>>> traffic.  However, we all know the pitfalls of that last statement,
>>>> especially on our networks!  We plan to start by logging RFC1918 traffic
>>>> only, and then move to blocking it.  We also plan to offer opt-outs for
>>>> customers who need them.  We would welcome your input on this, for our
>>>> benefit as well as for the benefit of other customers.
>>>>
>>>>
>>>> - Check your routing tables!
>>>> https://twitter.com/InternetIntel/status/1080466509292621829
>>>>
>>>>
>>>> - Hat tip to researchers at the University of Maryland!
>>>> https://www.theregister.co.uk/2019/01/03/recaptcha_voice_challenge/
>>>>
>>>>
>>>> - A lot of it, as it turns out.
>>>> http://nymag.com/intelligencer/2018/12/how-much-of-the-internet-is-fake.html
>>>>
>>>>
>>>> Happy new year, everybody!
>>>>
>>>> Adair
>>>
>>

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

Attachment: smime.p7s
Description: S/MIME cryptographic signature