Subject: [secdir] SecDir repeat review of draft-ietf-6renum-enterprise-05

From: Yaron Sheffer <[email-masked]>
Date: Thu, 03 Jan 2013 12:43:41 +0200

Hi,

version -05 of the draft responds to all the concerns I had with -04. I 
have no additional comments.

Thanks,
	Yaron

On 12/14/2012 12:34 PM, Yaron Sheffer wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> This document reviews best practices in renumbering IPv6 enterprise
> networks.
>
> I apologize for my belated review, and hope it is still useful to the
> authors and document reviewers.
>
> Summary
>
> The Security Considerations section appears appropriate for this type of
> document. I do not see any issues that should block the document from
> advancing.
>
> Details
>
> - Usage of FQDN: I don't understand why RFC 5996 (IKEv2) is cited, I
> suspect this is a typo. Otherwise, please clarify.
> - The "Security" subsection of 4.1 overlaps with the Security
> Considerations section, and I would recommend to consolidate them.
> - 4.1, "Miscellaneous": I accept the recommendation to use FQDNs instead
> of IP addresses. But saying "connections can survive" implies to me that
> live TCP connections will survive an IP renumbering event, which is not
> the case. I would say "connectivity to the remote side can survive"
> instead.
> - 4.3: RFC 2230 is mentioned as a way to deal with naming of IPsec
> endpoints. I am not aware of current implementations of this RFC (in
> fact it is not even mentioned in the current IPsec Roadmap document, RFC
> 6071). Moreover, there is community consensus that IPsec should not be
> used in the absence of a key management protocol. And IKE/IKEv2
> certainly supports naming/identifying endpoints by FQDN.
> - The Security Considerations are sufficient IMO. The first point (using
> renumbering to escape blacklisting) is appropriate in the context, even
> if per Martin Stiemerling's comment, this strategy may not be very
> effective. This is not a recommendation on how to bypass blacklisting,
> just a description of a potential vulnerability.
>
> Thanks,
>       Yaron
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 31 Jan 2013 19:42:58 +0200

This document describes a method to protect a network from router/link 
failures by encapsulating packets in an envelope that denotes what nodes 
it should *not* be routed through. This is not a protocol definition 
(despite a few stray MUSTs), it is only an informational summary of 
design issues and a framework.

Summary

The document is good to go. In fact, a SecDir review is not applicable.

Details

The document does contain a Security Considerations section that goes 
through 3 potential security issues. But since the document in general 
is a high-level discussion, it is impossible to analyze whether all 
pertinent security issues are covered. If the not-via mechanism is ever 
specified as a protocol, the security analysis will need to be done from 
scratch.

Thanks,
      Yaron