[Gen-art] Re: Partial review of draft-ietf-v6ops-security-overview-04.txt

Elwyn Davies <elwynd@dial.pipex.com> Thu, 24 August 2006 11:27 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDNB-00070B-Kv; Thu, 24 Aug 2006 07:27:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGDNA-000706-Po for gen-art@ietf.org; Thu, 24 Aug 2006 07:27:44 -0400
Received: from b.painless.aaisp.net.uk ([2001:8b0:0:81::51bb:5134] helo=smtp.aaisp.net.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGDN5-0005Tg-3m for gen-art@ietf.org; Thu, 24 Aug 2006 07:27:44 -0400
Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247] helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1GGDMe-00011z-VG; Thu, 24 Aug 2006 12:27:13 +0100
Message-ID: <44ED8DD1.9030508@dial.pipex.com>
Date: Thu, 24 Aug 2006 12:30:25 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Sharon Chisholm <schishol@nortel.com>
References: <713043CE8B8E1348AF3C546DBE02C1B408AADFBD@zcarhxm2.corp.nortel.com>
In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B408AADFBD@zcarhxm2.corp.nortel.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: david.kessens@nokia.com, fred.baker@cisco.com, gen-art@ietf.org, suresh.krishnan@ericsson.com, kurtis@kurtis.pp.se, psavola@funet.fi
Subject: [Gen-art] Re: Partial review of draft-ietf-v6ops-security-overview-04.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Errors-To: gen-art-bounces@ietf.org

Just running through the updates for this doc...

new version coming shortly for your inspection.

/Elwyn

Sharon Chisholm wrote:
> Attached is my review of the specified document, submitted as part of
> the Gen-ART process.  For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>
> Document:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-0
> 4.txt
>
> Summary: This draft is basically ready for publication, but has nits
> that
> 	should be fixed before publication.
>
> Comments:
>
> I somehow wasn't paying attention and only realized at the last minute
> that I was assigned this review for today's meeting. Apologies for the
> lateness and incompleteness of this review. I only managed to review to
> the end of section 2.3.
>
> 1. In section 1, second paragraph, it says "It is important to
> understand that we have to be concerned not about replacing IPv4 with
> IPv6", which seems a bit bold of a statement without a clarification
> like "in the near future" or some form of explanation.
>   
Slightly munged the words to make this clearer.
> 2. In section 2.1.1, second paragraph and after the bullets, there is a
> typo - "point wher it is being "
>   
ok
> 3. The document contains a number of references to internet drafts that
> originally defined the problems discussed. The document claims "Several
> of these issues have been discussed in separate drafts but are
> summarized here to avoid normative references that may not become RFCs",
> but it isn't clear what the RFC editor should do. Should it delete all
> these references or just delete the ones that are not RFCs at the time
> of publication, or should it evaluate which it thinks will someday
> become RFCs and then wait for them?
>   
I have removed all these expired drafts. expanded the discussion 
slightly where necessary to avoid the need to read the original draft 
and acknowledged the contributions in the Acknowledgment section.
> 4. Section 2.1.9. 1 does not make a recommendation. Are we suggesting
> that middleware boxes should inspect these packets or just letting
> people know about the conflict. A recommendation of some sort would seem
> more satisfying.
>   
Sentence added:
   Firewall vendors and administrators may
   choose to ignore these rules in order to provide enhanced security as
   this does not appear to have any serious consequences with the
   currently defined set of extensions, but administrators should be
   aware that future extensions might require different treatment.

> 5. In section 2.1.9.2, third paragraph says that "This either limits the
> security that can be applied in firewalls or makes it difficult to
> deploy new extension header types", but I did not find information in
> this section to support that conclusion. It may well be true, but it
> isn't supported. Why is it difficult to skip over header extensions I
> don't recognize, for example?
>   
Because without a mandate of TLV format (specifically the L value) you 
need implicit knowledge of how big the option is.  This is not a 
desirable state for an extensible system.  I gink this is clear now.
> 6. In section 2.3.2, second paragraph, second bullet, isn't it mandatory
> to implement ipsec in IPv6 but it isn't mandatory to deploy it is it?
> I'm not sure this distinction is clear in this bullet. (Assuming my
> understanding is correct that is) 
>   
No. It is not mandatory to *use* it.  All conforming implementations 
deployed must support IPsec.  There is no way to turn it off in a given 
deployment.

> 7. In section 2.4, it seems there are two typos: accpetable and
> mecahnism .
>   
Fixed.
> 8. In section 3.3, the term SOHO is used but not explained. I'm guessing
> it Small Office/Home Office after a bit of googling.
>
>   
Fixed
> 9. In appendix B, first paragraph it says "The generation of IPv6
> addresses of IPv6 addresses from MAC addresses" while I imagine it
> should read "The generation of IPv6 addresses from MAC addresses"
>   
Fixed.
> Sharon
>
>   

> Sharon Chisholm
> Nortel 
> Ottawa, Ontario
> Canada
>
>   

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art