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

So, can we agree on "NAT is not required to provide security in IPv6 (see
for example [RFC4864])."

I agree that this aspect of IPv6, including the appropriate use of ULAs,
is definitely hard to explain to people brought up on common IPv4 practice.

Regards
   Brian

On 17/06/2016 23:29, Marco Ermini wrote:
> I am sorry Brian, I don't think you understood my argument.  I am not arguing about you mention.  I am arguing against the semantic of a phrase that says "NAT does not provide security".  This sentence is semantically wrong, and usually comes from a priori NAT-haters (I have met a few).
> 
> I am only against stating such sentence in the RFC, not against the fact that we don't need NAT.  I hope this is clearer now.
> 
> Anyway, I have made my point sufficiently, I believe.
> 
> 
> Regards,
> Marco.
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
> Sent: Friday, June 17, 2016 3:40 AM
> To: Marco Ermini; 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 21:15, Marco Ermini 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.
> 
> Have you read RFC4864 recently? Section 4.4 is all about how you don't need NAT to hide infrastructure topology in IPv6.
> 
>> I personally don't sympathize on NAT-haters.  NAT has its reasons, especially for carrier-grade NAT and especially in the telco scenario, and yes, it does provide some level of security - again, not the complete picture, but it does.
> 
> That's IPv4. This is IPv6.
> 
>     Brian
> 
>>
>>
>> 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
>>
> 