IPv6 ingress filtering

[Brian E Carpenter]

On 18-May-19 09:07, Kurt Buff - GSEC, GCIH wrote:
> On Fri, May 17, 2019 at 1:59 PM Enno Rey <erey at ernw.de> wrote:
>>
>> Hi,
>>
>> On Fri, May 17, 2019 at 01:45:56PM -0700, Kurt Buff - GSEC, GCIH wrote:
>>> Forgive the intrusion, as I seek a bit of clarity.
>>>
>>> MSFT DirectAccess seems to use the address range in question:
>>>
>>> Tunnel adapter iphttpsinterface:
>>>
>>>    Connection-specific DNS Suffix  . :
>>>    IPv6 Address. . . . . . . . . . . : 2002:4332:aaaa:bbbb:cccc:dddd:eeee:ffff
>>>    Temporary IPv6 Address. . . . . . : 2002:4332:aaaa:bbbb:cccc:dddd:eeee:ffff
>>>    Temporary IPv6 Address. . . . . . : 2002:4332:aaaa:bbbb:cccc:dddd:eeee:ffff
>>>    Link-local IPv6 Address . . . . . : fe80::75e4:c4b3:fae6:237c%2
>>>    Default Gateway . . . . . . . . . :
>>>
>>> It seems to me that filtering this range might hurt a bit, unless I'm
>>> mistaking what some are proposing.
>>
>> not being an MS DirectAccess expert I'd say that - given DA is a VPN technology, using IP-HTTPS as a (somewhat proprietary) tunnel tech - these addresses shouldn't be visible too much "in the [public] IPv6 Internet" so the proposed filtering (of this thread) shouldn't come into play.
>>
>> cheers
>>
>> Enno
> 
> So, network filters aren't going to gratuitously inspect IPv4 packets
> for IPv6 content.

Let's hope not, but what possessed Microsoft to make them use the
2002::/16 prefix in this way is an interesting question in itself.
In 6to4 format, 4332:aaaa would imply a site IPv4 address of
67.50.170.170. And cccc:dddd:eeee:ffff doesn't look much like
a pseudo-random temporary interface identifier.

Maybe it's never a good idea to look underneath the hood of a VPN.

    Brian
> 
> Seems reasonable to me.
> 
> Thanks,
> 
> Kurt
> 
>>>
>>> Kurt
>>>
>>> On Fri, May 17, 2019 at 1:06 PM Brian E Carpenter
>>> <brian.e.carpenter at gmail.com> wrote:
>>>>
>>>> On 18-May-19 06:12, Gert Doering wrote:
>>>>> Hi,
>>>>>
>>>>> On Fri, May 17, 2019 at 12:55:33PM -0500, David Farmer wrote:
>>>>>> A few questions;
>>>>>>
>>>>>> Are you generating ICMPv6 toward non-2002::/16 sources for traffic destined
>>>>>> to 2002::/16?
>>>>>> Are you generating ICMPv6 toward 2002::/16 source for traffic destined to
>>>>>> non-2002::/16?
>>>>>> For the later, where are you getting the route for 2002::/16 from?
>>>>>
>>>>> Indeed, as you said, filtering correctly (= ICMP unreachable, so clients
>>>>> can fail over quickly [if HE is not in use]) is hard.
>>>>>
>>>>> We still run our own relay, so do not filter today.  Mostly because I
>>>>> know it works and (since it's our relay) I can rely on it to not break
>>>>> things for people - and haven't had time to change that to "filter".
>>>>
>>>> And surely the question is "What would produce the most help desk calls?".
>>>> Filtering something that is presumably working for its remaining users
>>>> might not be a good idea from that point of view.
>>>>
>>>>     Brian
>>
>> --
>> Enno Rey
>>
>> ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>> Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>>
>> Handelsregister Mannheim: HRB 337135
>> Geschaeftsfuehrer: Florian Grunow, Enno Rey
>>
>> =======================================================
>> Blog: www.insinuator.net || Conference: www.troopers.de
>> Twitter: @Enno_Insinuator
>> =======================================================
>