Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-01.txt

[Brian E Carpenter <[e-mail]>]

Hi,

Some comments (but this is not a full review).

> 2.1.2.  Use of ULAs
> 
>    ULAs are intended for scenarios where IP addresses will not have
>    global scope.  The implicit expectation from the RFC is that all ULAs
>    will be randomly created as /48s.  However, in practice some
>    environments have chosen to create ULAs as a /32.  

You should point out that this practice completely violates RFC 4193
and greatly reduces the probability of non-collision between ULA
prefixes. I am frankly amazed that anyone would do it.

BTW you need a reference to RFC 4193 in the text.

>    While ULAs can be
>    useful for infrastructure hiding

You could refer to RFC 4864 here. Actually, there are many places
in this draft where you could refer to RFC 4864.

>  (as they force the use of address
>    translation to reach the Internet), 

Absolutely wrong. The idea is that you would use ULAs for internal
traffic and simultaneously use a global address for external traffic.

>    it may create an issue in the
>    future if the decision at some point is to make the machines using
>    ULAs globally reachable.  This would require renumbering 

No, no, no. It would requiring giving such hosts (and only such hosts)
a global (PI or PA) address. That is standard operating procedure for IPv6.

>    or perhaps
>    even stateful IPv6 Network Address and Port Translation (IPv6 NAPT --
>    not an IETF work item).  

No, no, no. It would be possible (but is not recommended) to run stateless
NPTv6 (RFC 6296) for outbound access, but there is never a reason to
run translation for inbound access.

>    The latter would be problematic in trying to
>    track specific machines that may source malware although this is less
>    of an issue if appropriate logging is done which includes utilizing
>    accurate timestamps and logging a node's source ports [RFC6302].
> 
>    The use of ULA does not isolate 'by magic' the part of the network
>    using ULA from other parts of the network (including the Internet).
>    Routers will happily forward packets whose source or destination
>    address is ULA as long as they have a route to the destination and
>    there is no ACL blocking those packets.  

Again, please read and refer to RFC 4193:

   The default behavior of exterior routing protocol sessions between
   administrative routing regions must be to ignore receipt of and not
   advertise prefixes in the FC00::/7 block.  A network operator may
   specifically configure prefixes longer than FC00::/7 for inter-site
   communication.

You are correct that there is no magic, but border routers MUST filter
ULA prefixes. That filter, or an equivalent ACL, is mandatory.

> 2.1.3.  Point-to-Point Links
> 
>    [RFC3627] indicates that the use of a /64 is the best solution for
>    point-to-point links while a /112 can be used if that's not
>    possible.

RFC 3627 is obsolete and historic - you should only mention it to
say so (see RFC 6547). This whole paragraph should be rewritten to
discuss RFC 6164 only.

> 2.1.4.  Privacy Extension Addresses

I think it is better to use the correct terminology from
RFC 4941: "Temporary Addresses".

>    Since MAC addresses for specific
>    vendor equipment can be know, it may be easy for a potential attacker
>    to perform a more directed intelligent scan to try and ascertain
>    specific vendor device reachability for exploitation.  Privacy
>    extensions attempts to mitigate this threat.

That is misleading. This mitigation is a side-effect of temporary
addresses; the design motivation was to protect user privacy.

>    As privacy extensions could also be used to hide illegal and unsavory
>    activities, privacy extensions addresses can be assigned, audited,
>    and controlled in managed enterprise networks via DHCPv6.

How? Where is that described? How is privacy ensured if an address is
assigned by DHCP?

> 2.3.3.  Packet Exceptions
...
>    o  processing of the hop-by-hop extension header.  See
>       [I-D.krishnan-ipv6-hopbyhop]

Expired draft.

>    On some routers, not everything can be done by the specialized data
>    plane hardware which requires some packets to be 'punted' to the
>    generic RP.  This could include for example the processing of a long
>    extension header chain in order to apply an ACL based on layer 4
>    information.

You probably need to look at draft-ietf-6man-oversized-header-chain
and expand this text. Also look at draft-carpenter-6man-ext-transmit
which discusses another aspect of the problem, with discussion of
what firewalls should do.

> 2.6.2.  Transition Mechanisms
...
>    To mitigate the bypassing of security policies, it could be helpful
>    to block all default configuration tunnels by denying all IPv4
>    traffic matching:

This is too simple and discourages baby steps towards IPv6. A better
statement would be:

- If offering IPv6 service to end-users, there is no need for 6-in-4
  tunnels of any kind, so they can be blocked.

- If not offering IPv6 service to end-users, a specific decision is
  needed about which tunneling mechanism will be available for
  early adopters; that can be allowed, others can be blocked.

> 2.6.2.4.  6to4
...
>    They suffer from several technical issues as well as security issues
>    [RFC3964].  Their use is no longer recommended (see
>    [I-D.ietf-v6ops-6to4-to-historic]).

That draft was dropped after IETF Last Call and is officially dead, so
the sentence is inaccurate. Replacement:

   Client usage of 6to4 by default is now discouraged, and significant
   precautions are needed to avoid operational problems [RFC6343].

>From a security PoV, that RFC notes:

   However, it should
   be noted that if an operator provides well-managed servers and relays
   for 6to4, non-encapsulated IPv6 packets will pass through well-
   defined points (the native IPv6 interfaces of those servers and
   relays) at which security mechanisms may be applied.

In other words, operating 6to4 correctly reduces security risks,
compared with ignoring it.

> 3.2.  Internal Security Considerations:
...
>    Automated IPv6-in-IPv4 tunnels (see Section 2.6.2) should also be
>    blocked to avoid bypassing the IPv4 security policy.

Again, too simple, see my above comment under "Transition Mechanisms".

Regards
   Brian Carpenter