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

On 16 June 2016 at 19:15, Marco Ermini <Marco.Ermini@resmed.com> wrote:
> Well, actually, infrastructure hiding IS part of security.  It is not the full picture, but it is incorrect to say that it is not.
>
> I personally don't sympathize on NAT-haters.  NAT has its reasons, especially for carrier-grade NAT

CGN isn't necessary in IPv6, it's to solve the problem of ISPs running
out of IPv4 addresses.

 and especially in the telco scenario, and yes, it does provide some
level of security - again, not the complete picture, but it does.
>

NAT is not necessary in IPv6. The equivalent of NAT's perceived
security can be provided via alternative methods, as described in
RFC4864.

A further technique to hide topology that isn't mentioned in RFC4864
is to use something like ISATAP or similar, to create a single /64
subnet over the top of multiple IPv4 subnets. Externally, all hosts
will appear to belong to a single IPv6 subnet, hiding the internal
topology.

If you truly want to hide the identities of hosts, NAT doesn't do
enough - it is only translating addresses, where as there are many
other host identifiers that the host itself supplies or will receive
and supply that can identify hosts e.g. HTTP cookies. "A Technique for
Counting NATted Hosts"
(https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field
within the IPv4 header that leaked across a NAT was able to be used to
identify hosts.

If you truly want to hide a host from the Internet, yet still allow it
to access things on the Internet, under IPv6 your network would use
ULA addressing, and have a per-application protocol proxy server that
makes all requests look like they've entirely originated from the
application proxy server itself. To the Internet server, the
application proxy server would appear to be the application end host
making the requests, preventing any internal host identifiers or other
attributes from leaking.

Regards,
Mark.

>
> Regards,
>
> Marco Ermini
>
> CISSP, CISA, CISM, CEH, ITIL, MCP, PhD
> Senior IT Security Analyst
> D +49 (0)899 901 1523  M +49 (0)175 439 5642
>
> ResMed Germany Inc
>
>
> -----Original Message-----
> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: Thursday, June 16, 2016 1:45 AM
> To: Erik Kline; Eric Vyncke (evyncke)
> Cc: fgont@si6networks.com; opsec@ietf.org; linkedin@xn--debrn-nva.de; draft-ietf-opsec-v6@ietf.org; v6ops@ietf.org
> Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08
>
> On 16/06/2016 07:45, Erik Kline wrote:
>> Section 2.1.2 is far too permissive for my tastes.  We need to be able
>> to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF.
>
> I have strong sympathy with that statement, but I don't think this is the document to do it; the point is made in RFC4864 too. What we should do here is underline that NAT != security.
>
> While I'm here, some other points:
>
> "2.2.  Extension Headers
>
>    TBD, a short section referring to all Fernando's I-D & RFC."
>
> That's not the whole story ;-). Firstly, RFC 7045 has a lot of relevance to security aspects. Second, there is no reason to refer to most of the material (Fernando's or not) unless it's directly relevant to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering,
> but only if that document is going anywhere.
>
> "2.3.3.  ND/RA Rate Limiting
> ...
>    The following drafts are actively discussing methods to
>    rate limit RAs and other ND messages on wifi networks in order to
>    address this issue:
>
>    o  [I-D.thubert-savi-ra-throttler]
>
>    o  [I-D.chakrabarti-nordmark-6man-efficient-nd]"
>
> Neither of those drafts is in the least active (from 2012 and 2015 respectively). Dead drafts are of no help to the reader, IMHO.
>
> "4.2.  Transition Mechanism
>
>    SP will typically use transition mechanisms such as 6rd, 6PE, MAP,
>    DS-Lite which have been analyzed in the transition Section 2.7.2
>    section."
>
> Shouldn't you add RFC6877 464XLAT now?
>
> Finally, I think there should be a Privacy Considerations section.
>
> Rgds
>     Brian
>
>>
>> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well.  We
>> should, in my opinion, make it painfully clear that DHCP (of any
>> protocol) in the absence of link-layer security/auditability features
>> does not provide any satisfactory way "to ensure audibility and
>> traceability" [Section 2.1.6].
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops