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

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 25 May 2006 10:54:44 -0400

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.

2. In section 2.1.1, second paragraph and after the bullets, there is a
typo - "point wher it is being "

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?

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.

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?

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) 

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 25 May 2006 16:52:31 +0100

> like "in the near future" or some form of explanation.
The sentence is intended to mean that we aren't going to see the 
all-IPv4 net going away to be replaced by the all-IPv6 network (in the 
short term - actually that is an understatement- more like the long 
teerm). Instead we have to deal with co-existence for a very long time.

Maybe the words could be improved.

> become RFCs and then wait for them?
I believe that it is OK to leave the references as 'work in progress' 
since they are informative in an Informational document.
> people know about the conflict. A recommendation of some sort would seem
Yes it would... unfortunately this is difficult because doing what is 
advisable breaks the letter of the IPv6 standard and doing what the 
standard says can lead to a security hole.  IMO the standard should be 
fixed but that is not something we can recommend or expect here- so we 
can point out that you can do it and leave it to operators to do as they 
see fit.  Recommending either way would be to upset somebody.
> don't recognize, for example?
Because there is no guarantee that a random new header is in the right 
TLV format.  It alsmost certainly would be but the standard doesn't 
*guarantee* it.  Again this ought to be fixed.
> understanding is correct that is) 
A conforming implementation has to implement it - and hence it *should* 
be deployed.  The choice is whether the user chooses to use it for any 
given session.  I think the statements in the section are correct.

Regards,
Elwyn