[ipv6hackers] (IETF I-D); Implications of IPv6 Addressing on Security Operations (Fwd: New Version Notification for draft-gont-opsec-ipv6-addressing-00.txt)

[Fernando Gont]

Hi, Andy,

In-line....


On 5/2/23 05:18, Andrew Walding wrote:
>>
> 
> Most network security folks have adopted the "zero trust" formula as their
> guiding light these days.  I think this needs to be mentioned as perhaps a
> new paragraph 2 in section 1.
> 
> Further I would add a paragraph in section1 before that last paragraph that
> plainly states:
> 
> A well developed experience level with IPv4 addressing and traffic
> monitoring/firewalling and security policy development has been ingrained
> in network designs.  As these networks deploy IPv6 the complexity of
> security policies has to expand to consider multicast, global unicast,
> unique local, link local, and other address types.  In simple terms, you
> cannot deal with IPv6 security policies the same way you have dealt with
> IPv4.

[me thinking out loud, more than arguing against]
I'd be skeptical in e.g., mentioning multicast or e.g. link-local 
addresses, since that seems to be more of a general firewalling issue 
than an IPv6-addresss ACL one.

e.g., there's multicast in IPv4, too. It just happens that in IPv6, 
multicast is employed even fore regular and core functionality such as 
Neighbor Discovery.




>> Do you mean, e.g., that the draft should e.g. provide advice such as "do
>> not block a single /128, bur rather consider blocking a /64 at a
>> minimum", and the like? or something else?
>>
>>
> Well not exactly.  Here are some example policies I can think of - not sure
> if they all apply, but forgive me while I brain dump below.
> Implementers may choose to combine some of these example policies.  Also
> forgive me if I get some details wrong as I am typing this off the top of
> my head.  Also, since RFC4890 covers ICMP access lists I leave that alone
> -but that might be worth mentioning in your draft as a reference.
> 
[...]

As noted above, these are indeed valid, but it seems to go beyond the 
(at least original) scope of this document. Our original intent was to 
discuss how security operations involving IP addresses conceptually 
change. e.g.:

* If you want to allow incoming connections from a specific host, beware 
of temporary addresses which will result in the same host regularly 
changing its addresses -- therefore, either disable temporary addresses 
or specify the allow list as a /64.

* When configuring block-lists, please note that IPv6 attackers will 
typically control way more than a /64 -- hence the granularity of 
block-lists should be the same... or otherwise a skilled attacked could 
easily circumvent such block-lists.


That said, it probably does make sense to mention e.g., the multiple 
prefixes a host may employ, since it might be a "gotcha" that folks 
configure e.g. an allow-list for one prefix (e.g. global prefix in a 
private network) but the source address selection rules causes the host 
to choose a different source prefix/address and hence the ACL fails.



> Example #2:  Dealing with Unique Local Addresses RFC4193 on the WAN
> interface. Even though some of this address space is technically not to be
> used per RFC guidance, most router platforms fully support the FC00::/8 and
> FD00::/8 address space.  It is likely that we should never expect ULA
> traffic going out to the global addressing space.
>    ipv6 access list blockv6ula
>      deny ipv6 any fd00::/8      #we should never see any traffic going to
> the fd00::/8 coming from the WAN interface
>      deny ipv6 any fc00::/8      #we should never see any traffic going to
> the fc00::/8 coming from the WAN interface
>      permit ipv6 any any     #permit all other ipv6 traffic

As with some of the above, this one seems to fall more into a general 
firewalling issue (bogon filtering, so to speak). -- but it might be 
sensible to cover this in this document -- particularly if thereś no 
other document that covers this.

-- I will certainly raise this question to the opsec wg 
(https://datatracker.ietf.org/wg/opsec/about/) , where this document is 
targeted.


> Example #5:  Dealing with an intrusive or misbehaving ipv6 source.  The
> tendency here is to create either a whitelist or blacklist collection of
> allowed or banned addresses.  In an IPv4 network this is relatively
> straight forward as an interface most likely has only one address.
> Further, it does not matter whether the source is a server or client, in
> the IPv4 space these addresses tend not to change.  In IPv6 this could also
> be the case, however there are further considerations.
> 5-1: If it is a source that has a single Global Unicast Address, first it
> is likely a server, though some clients may also follow this single address
> deployment, then the full /128 bit address must be added to the
> blocked/banned list.

The question here is: how can you tell if it has a single address? (from 
an external pov)



> 5-2: if the source has deployed RFC4941/RFC8981 then it may use multiple
> random IID's over time - it is likely to not be a server.  Most temporary
> addresses are used for outgoing communications and stable addresses are
> used for incoming communications.  With any given /64 prefix having 18
> quintillion possible IID's, there are two possible problems. 1) Choosing to
> ban the entire prefix may ban legitimate sources/destinations in that
> prefix including the misbehaving source, or 2) choosing to ban the
> additional temporary addresses generated by the interface greatly increases
> the size of the blacklist (it should be noted here that most operating
> systems that support these RFC's generate at most 4 additional temporary
> addresses so best case this is a 4x problem

Given the typical lifetimes in RFC4941, they actually generate up to 
seven addresses ("valid lifetime / preferred lifetime")


[...]
> 5-4: EUI64 - not sure if a special case is needed for the FFFE IID
> format, or any IID format for that matter.  If the attacking host is
> changing prefixes, and they use the fixed EUI64, it may be possible to
> create a policy that blocks that EUI64 IID.  Again so few ipv6 hosts use
> this anymore I am not sure it is necessary.  This is a fringe example.

Agreed on this. And in the case of legacy hosts that use EUI64 IIDs, 
most likely they implement RFC4941 -- so it's quite unlikely that you´d 
see an attacking host roaming around attacking from its EUI64 IID.



> I think example 5 was where the main thrust of your draft was headed, and
> perhaps I have overstepped your boundaries, if so forgive me. 

You raise a valid point. It might make sense to expand the scope. 
Although in that case, I'm not sure if one would/should just expand the 
scope about filtering based on IPv6 src/dst, or also on a per-protocol 
type. (i.e., whether you allow/deny a specific src/dst might depend on 
whatś the protocol using it... e.g., particularly for the multicast 
case). BUt if one gets into that that might be a very different document 
(much larger scope).

Still, it's a valid question to pose to the opsec wg.

P.S.: For all those reading this thread, please consider joining the 
opsec wg mailing list (https://www.ietf.org/mailman/listinfo/opsec) -- 
the IETF wg this document is targeted at.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494