Re: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08

["Eric Vyncke (evyncke)" <[e-mail]>]

Fred,

First thank you for the review, to be honest I was unaware that per RFC
2119 "SHOULD" was a synonym of "RECOMMENDED" ;-) And you suggestion of
listing all recommendations is indeed a good idea (but I am afraid that we
won't have time to add it for the -09 rev).

All other comments are accepted with a few exceptions below. EVY>>

Thanks again :-)

-éric


On 15/06/16 22:05, "Fred Baker (fred)" <[e-mail]> wrote:

>One thing I wondered about as reading this - many and perhaps most
>sections gave a fairly informative comment, and then made one or two
>recommendations. I wonder (this is a question) whether it would be
>worthwhile capitalizing "RECOMMEND", both in the sense of defining the
>term (RFC 2119) and highlighting it in the text. I also wonder if it
>would make sense to pull together a list of recommendations made in a
>table somewhere, perhaps in an appendix. I could imagine someone wanting
>a list of them without wading through the text.
>
>> 1.  Introduction
>> 
>>    Running an IPv6 network is new for most operators not only because
>>    they are not yet used to large scale IPv6 networks but also because
>>    there are subtle differences between IPv4 and IPv6 especially with
>>    respect to security.  For example, all layer-2 interactions are now
>>    done by Neighbor Discovery Protocol [RFC4861] rather than by Address
>
>s/by/using/, twice. As worded, it sounds like NDP and ARP doing this by
>themselves, as *actors*; no, the *system* does them using NDP and ARP as
>its *language*.
>
>>    Resolution Protocol [RFC0826].  Also, there are subtle differences
>>    between NAT44 and NPTv6 [RFC6296] which are explicitly pointed out in
>>    the latter's security considerations section.
>
>For NAT44, I might also point to RFC 2993 and maybe 4864.
>
>>    IPv6 networks are deployed using a variety of techniques, each of
>>    which have their own specific security concerns.
>
>
>> 2.  Generic Security Considerations
>> 
>> 2.1.  Addressing Architecture
>> 
>>    IPv6 address allocations and overall architecture are an important
>>    part of securing IPv6.  Typically what you initially design for will
>>    be what you use for a very long time.
>
>This sentence is in the second person ("you"), and most of the document
>is third person ("it"). Reword as "Initial designs, even if intended to
>be temporary, tend to last much longer than expected"?
>
>> Although initially IPv6 was
>>    thought to make renumbering easy, in practice, it would be extremely
>>    difficult to renumber.
>
>I would temper the statement. As we said in RFC 4192, the problems with
>renumbering tends to be the places where a number is written into a
>static configuration rather than managed using a database or whatever,
>and the places where people cut corners ("its address will never change,
>so I don't need to worry about its name and DNS"). I would find myself
>saying that good OSS trumps static configurations, and in IPv6, systems
>change at least their IIDs from time to time (RFC 7721). It's not that
>IPv6 (or IPv4) is hard to renumber, it's that the required operational
>support is often not there or not workable due to poor practice.
>
>>    Once an address allocation has been assigned, there should be some
>>    thought given to an overall address allocation plan.  With the
>>    abundance of address space available, an address allocation may be
>>    structured around services along with geographic locations, which
>
>"topology"? Topology is often structured geographically, yes, but if A
>provides services to B and C and is a logical gateway to them, A, B, and
>C can be grouped for management purposes even if they are not in the same
>geographic location.

EVY>> we wrote "around services along with geographic locations" which
appears to me pretty much what you wrote above (i.e. A mix of services and
proximity)

>
>>    then can be a basis for more structured security policies to permit
>>    or deny services between geographic regions.
>> 
>>    A common question is whether companies should use PI vs PA space
>>    [RFC7381] but from a security perspective there is little difference.
>
>comma after "[RFC7381]".
>
>>    However, one aspect to keep in mind is who has ownership of the
>>    address space and who is responsible if/when Law Enforcement may need
>>    to enforce restrictions on routability of the space due to malicious
>>    criminal activity.
>
>Pregnant statement. I find myself wondering about the implications of
>"ownership" and "law enforcement restrictions on routability". In
>"ownership", are you pointing to issues when you change providers and
>therefore need to change PA addresses? If not, something else? In "LEA
>issues", are you talking about law enforcement blocking the address
>space, turning BGP announcements off, etc?

EVY>> Good point, I rephrased it as "However, one aspect to keep in mind
is who has administrative ownership of the address space and who is
technically responsible if/when there is a need to enforce restrictions on
routability of the space due to malicious criminal activity."

>
>
>> 2.1.1.  Statically Configured Addresses
>> 
>>    When considering how to assign statically configured addresses it is
>>    necessary to take into consideration the effectiveness of perimeter
>>    security in a given environment.  There is a trade-off between ease
>>    of operational deployment where some portions of the IPv6 address
>>    could be easily recognizable for operational debugging and
>>    troubleshooting versus the risk of scanning; [SCANNING] shows that
>>    there are scientifically based mechanisms that make scanning for IPv6
>>    reachable nodes more realizable than expected.  The use of common
>>    multicast groups which are defined for important networked devices
>>    and the use of commonly repeated addresses could make it easy to
>>    figure out which devices are name servers, routers or other critical
>>    devices.
>> 
>>    While in some environments the perimeter security is so poor that
>>    obfuscating addresses is considered a benefit; it is a better
>>    practice to ensure that perimeter rules are actively checked and
>>    enforced and that statically configured addresses follow some logical
>>    allocation scheme for ease of operation.
>
>I find myself on both sides of the prophylactic security discussion. I
>compare and network and its defenses to the human immune system, and
>perimeter security to the skin. I favor having a working perimeter
>security system much like I favor a functional skin, and for the same
>immunologic reasons. That said, the body provides the defense, reducing
>the rate at which it needs to bring other systems into play, and then
>assumes it has been breached; a person whose only immunologic defense is
>their skin is an AIDS patient, and doesn't have a good prognosis. My
>fundamental problem with most network security systems is that they
>over-emphasize perimeter security.
>
>I say that because this paragraph seems to over-emphasize perimeter
>security - "in some environments the perimeter security is so poor...". I
>think I would say that "security is so poor". I would be tempted to go
>beyond to talk about the ways a remote network can be mapped, such as by
>observing email envelopes and addresses found in WWW logs etc, and the
>value of temporary random addresses (as opposed to permanent addresses,
>whether DHCP -assigned or MAC/SLAAC).
>
>But I agree with the recommendation.
>
>> 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.  Any use of ULAs that are not
>>    created as a /48 violates RFC4193 [RFC4193].
>
>Mention also that they are expected to not be announced, and if announced
>not accepted, in BGP?
>
>>    ULAs could be useful for infrastructure hiding as described in
>>    RFC4864 [RFC4864];
>
>I believe that at least one cable operator uses them for cable modem
>addresses, which need no GUA and want to be hidden. Personally, I think
>that's a better use of a ULA - for something does doesn't actually need a
>global address. The paragraph here seems to assume that the only valid
>use of a ULA is as a counterpart to RFC 1918, and with NAT.
>
>I'd really wish that we could talk about infrastructure (count the
>addresses in the envelope of this email; they are mostly infrastructure
>addresses) and internal-only services (wwwin-SERVICE.cisco.com names
>being a classic Cisco example, to my mind) when we start a paragraph with
>a comment on "infrastructure hiding", rather than proceeding directly to
>NAT.

EVY>> I will rely on my co-author for this part.

>
>> 2.1.4.  Temporary Addresses - Privacy Extensions for SLAAC
>> ...
>>    As privacy extension addresses could also be used to obfuscate some
>>    malevolent activities (whether on purpose or not), it is advised in
>>    scenarios where user attribution is important to disable SLAAC and
>>    rely only on DHCPv6.  However, in scenarios where anonymity is a
>>    strong desire since protecting user privacy is more important than
>>    user attribution, privacy extension addresses should be used
>
>No mention of IEEE 802.1X?
>
>>    Using privacy extension addresses prevents the operator from building
>>    a priori host specific access control lists (ACLs).  It must be noted
>>    that recent versions of Windows do not use the MAC address anymore to
>>    build the stable address but use a mechanism similar to the one
>>    described in [RFC7217], this also means that such an ACL cannot be
>>    configured based solely on the MAC address of the nodes, diminishing
>>    the value of such ACL.  On the other hand, different VLANs are often
>>    used to segregate users, then ACL can rely on a /64 prefix per VLAN
>>    rather than a per host ACL entry.
>
>"then ACL"? Either I don't understand the sentence, or you meant "the".
>
>
>> 2.1.6.  DHCP/DNS Considerations
>> 
>>    Many environments use DHCPv6 to allocate addresses to ensure
>>    audibility and traceability (but see Section 2.6.1.5).  A main
>
>audit-ability
>
>>    security concern is the ability to detect and mitigate against rogue
>>    DHCP servers (Section 2.3.2).
>
>I think you want to say "counteract" rather than "mitigate against".
>
>> 2.3.5.  3GPP Link-Layer Security
>> 
>>    The 3GPP link is a point-to-point like link that has no link-layer
>>    address.  This implies there can only be an end host (the mobile
>>    hand-set) and the first-hop router (i.e., a GPRS Gatewat Support Node
>
>Gateway
>
>> 2.4.  Control Plane Security
>> 
>>    RFC6192 [RFC6192] defines the router control plane and this
>>    definition is repeated here for the reader's convenience.
>
>Run-on sentence. Replace "and" with a period and capitalize the next word.
>
>>    Modern router architecture design maintains a strict separation of
>>    forwarding and router control plane hardware and software.  The
>>    router control plane supports routing and management functions.  It
>>    is generally described as the router architecture hardware and
>>    software components for handling packets destined to the device
>>    itself as well as building and sending packets originated locally on
>>    the device.
>
>I'm having trouble parsing the above sentence...

EVY>> copied ad verbatim from RFC 6192 ;-) Else, I agree with you

>
>> The forwarding plane is typically described as the
>>    router architecture hardware and software components responsible for
>> 
>> 
>> 
>> Chittimaneni, et al.   Expires September 22, 2016              [Page 11]
>> Internet-Draft                 OPsec IPV6                     March 2016
>> 
>> 
>>    receiving a packet on an incoming interface, performing a lookup to
>>    identify the packet's IP next hop and determine the best outgoing
>>    interface towards the destination, and forwarding the packet out
>>    through the appropriate outgoing interface.
>
>I'm having trouble parsing the above as well. I'd suggest breaking it
>into 2-3 sentences.

EVY>> see above ;-)

>
>> 2.4.3.  Packet Exceptions
>> 
>>    This class covers multiple cases where a data plane packet is punted
>>    to the route processor because it requires specific processing:
>> ...
>>    o  processing of the hop-by-hop extension header;
>
>May I suggest the authors comment on draft-ietf-6man-hbh-header-handling
>as it progresses? Let's not let that and this conflict.
>
>> 2.6.1.1.  Logs of Applications
>> ...
>>    #!/usr/bin/perl ?w
>
>Should that be "-w"?
>
>>    use strict ;
>>    use warnings ;
>>    use Socket ;
>>    use Socket6 ;
>> 
>>    my (@words, $word, $binary_address) ;
>> 
>>    ## go through the file one line at a time
>>    while (my $line = <STDIN>) {
>>      chomp $line;
>>      foreach my $word (split /[ \n]/, $line) {
>
>replace "[ \n]" with "\s+". \s includes any white space character,
>including a space, a tab, \n, \r, and a couple of others. The "+"
>specifies strings of one or more in length.

EVY>> shame on me :-( You are right

>
>>        $binary_address = inet_pton AF_INET6, $word ;
>>        if ($binary_address) {
>>          print inet_ntop AF_INET6, $binary_address ;
>>        } else {
>>          print $word ;
>>        }
>>        print " " ;
>>      }
>>      print "\n" ;
>>    }
>
>
>> 2.7.1.  Dual Stack
>> 
>>    Dual stack has established itself as the preferred deployment choice
>>    for most network operators without a MPLS core where 6PE RFC4798
>
>without *an* MPLS core...
>
>> 2.7.3.2.  NAT64/DNS64
>> 
>>    Stateful NAT64 translation [RFC6146] allows IPv6-only clients to
>>    contact IPv4 servers using unicast UDP, TCP, or ICMP.  It can be used
>>    in conjunction with DNS64 [RFC6147], a mechanism which synthesizes
>>    AAAA records from existing A records.
>> 
>>    The Security Consideration sections of [RFC6146] and [RFC6147] list
>>    the comprehensive issues.  A specific issue with the use of NAT64 is
>>    that it will interfere with most IPsec deployments unless UDP
>>    encapsulation is used.  DNS64 has an incidence on DNSSEC see section
>>    3.1 of [RFC7050].
>
>You might want to mention 6145, draft-bao-v6ops-rfc6145bis, and SIIT-DC.
>
>> 3.1.  External Security Considerations:
>
>You mention having a firewall that only permits inbound traffic that
>corresponds to an active session. Would RFC 6092 be worth mentioning in
>that context?
>
>> 5.  Residential Users Security Considerations
>
>Would RFC 6092 be worth mentioning in this context?

EVY >> it is mentioned in this section
>