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

[Andrew Walding]

Hi Fernando,
Similarly inline....

On Sat, Feb 4, 2023 at 8:46 PM Fernando Gont <fernando at gont.com.ar> wrote:

> Hi, Andy!
>
> Nice to hear from you! (and thanks for the prompt response!) -- In-line...
>
>
> On 4/2/23 12:04, Andrew Walding wrote:
> > Hi Fernando,
> > There is a typo in Section 4.1 I think (sunch instead of such).
> > .
> > A couple of general comments.
> > I think this is a good subject and one that probably needs guidance as
> this
> > document suggests.  That said, I have the following thoughts:
> >
> >     - I will start by being a bit picky.  I think the wording describing
> the
> >     issues is spread too vaguely and needs to be more specific as to the
> >     addressing issues.  For example in your email you say compared to
> IPv4
> >     where you are usually dealing with "an" address from a private or
> public
> >     network, but in IPv6 a given host could have multiple addresses in
> multiple
> >     prefixes/networks then compounded with the various address types of
> IPv6,
> >     yet this is muddled in the document itself.  I mean that is the
> point in
> >     the end - you cannot deal with IPv6 the same way you deal with IPv4
> in this
> >     security scenario.
>
> Could you elaborate a bit?
>

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.


>
> >     - Now let me be general in this second point.  I think there is a
> >     big piece missing in this document, and that is what are the correct
> ways
> >     of thinking when it comes to these scenarios with IPv6.  you
> certainly hint
> >     at them, and for those who have implemented IPv6 in firewalls, we
> get where
> >     you are going, but the problem is you really never get to the end
> game in
> >     this draft.  Perhaps that was your intent, so that future drafts
> would add
> >     the necessary detail.
>
> 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.

Example #1:  Dealing with Multicast, especially multicast based scans.
This type of access list would be deployed at the border - the WAN
interface towards a service provider from an institution/business/perhaps
even home.  Implemented on that WAN interface on the inbound traffic ports:
ipv6 access list blockv6scan
    deny ipv6 any fec0::/10       #we should never see any traffic from
this prefix as it was deprecated in RFC3879
    deny ipv6 any ff02::/16      #there should never be any link local
scope destination multicast traffic on that WAN interface, except to the
WAN interface itself
    permit ipv6 any ff0e::/16     #allow the global scope multicast traffic
    deny ipv6 any ff00::/8        #block anything multicast left over
    permit ipv6 any any     #permit all other ipv6 traffic

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

Example #3:  Dealing with Documentation Address prefix RFC3849.  Even
though this address space is technically not to be used per RFC guidance,
most router platforms fully support the 2001:0DB8::/32 address space.  It
is likely that we should never expect sources or destination addresses
using this prefix anywhere in the network.
  ipv6 access list blockv6doc
    deny ipv6 any 2001:0db8::/32      #we should never see any traffic
going to the doc prefix
    deny ipv6 2001:0db8::/32 any      #we should never see any traffic
coming from the doc prefix to any ipv6 destination
    permit ipv6 any any     #permit all other ipv6 traffic

Example #4:  Dealing with IPv6 mapped IPv4 addresses.  It is likely that we
should never expect sources or destination addresses using this prefix
anywhere in the network.  Service providers will want to be cautios here is
they have deployed 6PE in MPLS networks.
  ipv6 access list blockv6mapv4
    deny ipv6 any ::ffff/96      #we should never see any traffic going to
the mapped prefix
    deny ipv6 ::ffff/96 any      #we should never see any traffic coming
from the mapped prefix to any ipv6 destination
    permit ipv6 any any     #permit all other ipv6 traffic

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.
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, and with that said it can be
expected that there will be settings and scripts that will alter this
default OS behavior to generate perhaps hundreds).  One approach would be
to allow up to some number of individual addresses into the blocked list,
and once that threshold is reached, the /64 prefix is then banned.
5-3: if the source has deployed RFC7217, the source is generating an
unpredictable but stable IID.  It is not possible to reverse engineer the
function even though the prefix is known, the other three components will
not be known.  Like the temporary address manipulation, the generation of
multiple RFC7217 addresses is possible.  We are left with the same two
problems as described in 5-2.
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.

Example #6:  Protocol 41 traffic.  This is IPv6 inside IPv4 traffic.  A
network manager must decide if this traffic is going to be allowed.  This
includes ISATAP, 6to4, 6rd and other tunnelled IPv6 traffic types.

Example #7: If NAT64/DNS64 is deployed, then specific permit statements
need to be added to policies to allow the WKP 64:ff9b::/96 and whatever NSP
prefixes are selected, along with IPv4 address ranges configured into the
NAT system.


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.  Certainly
there is room in example 5 to be even more specific.  Also readers of this
email, if you have windows machines you can view these ipv6 addresses with
the following commands:

   - netsh int ipv6 show join       #this command will show all ipv6
   multicast address groups each of your interfaces has joined.
   - netsh int ipv6 show address     #this command will show what ipv6
   addresses (dhcp, public, temporary, other - Microsofts names) are assigned
   to each interface.  No multicast info.
   - ipconfig    #yup that will do the same as the command above, as well
   as show ipv4 config. Also no multicast info.