Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Oct 2012 14:49:31 +0100

Hi,

A few comments. I expect I will have more when the TBD sections are written.
I am not on the opsec list.

> This document complements [RFC4942] by listing all security issues

That is a remarkable claim ;-). I think you mean

 This document complements [RFC4942] by listing all known security issues

> 3.1.  External Security Considerations:
...
>    o  Accept certain ICMPv6 messages to allow proper operation of ND and
>       PMTUD, see also [RFC4890]

This seems a very incomplete summary of the message of RFC 4890, which has
a full analysis and recommendations. In fact (IMHO) it should be a BCP,
since the correct behaviour is required for connectivity to work.

>    o  Filter specific extension headers, where possible

Please consider citing draft-carpenter-6man-ext-transmit, which discusses
what firewalls need to do about extension headers.

Also - why doesn't this section refer to RFC 4864, which is largely about
external security considerations?

> 5.  Residential Users Security Considerations
...
>    If the Residential Gateway has IPv6 connectivity, [RFC6204] defines
>    the requirements of an IPv6 CPE

Please update to 6204bis.

Regards
    Brian Carpenter

---

From: Merike Kaeo <[email-masked]>
Date: Sat, 6 Oct 2012 08:37:10 -0700

Appreciate the review and initial comments....some replies embedded below...

> This document complements [RFC4942] by listing all known security issues

Yes, some word smithing still required everywhere since the intent is to give enough input to operators to
ensure this document gives definitive guidelines but also points to the RFCs that detail all the specifics.  We will
edit this section.

> since the correct behaviour is required for connectivity to work.

Will add some wording here as well to be a bit more complete.

> external security considerations?

Probably simply an oversight which I'm happy you have pointed out.  Will look into this.

> Please update to 6204bis.

Yes.

- merike

---

From: Fernando Gont <[email-masked]>
Date: Sat, 06 Oct 2012 17:55:47 +0200

> what firewalls need to do about extension headers.

Wasn't aware about this I-D:

1) What's the plan for it?

2) It should probably reference draft-ietf-6man-oversized-header-chain,
since it means that you can safely drop first-fragments that fail to
include the entire IPv6 header chain.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Oct 2012 22:16:36 +0100

Hi Fernando,

> 1) What's the plan for it?

We've requested a slot in 6man at the Atlanta IETF. Obviously, if it moves
forward, it will also need security review.

> include the entire IPv6 header chain.

I will note that for the next version, thanks.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 06 Oct 2012 23:25:01 +0200

> forward, it will also need security review.

Good. -- I'd be willing to review. Please let me know if you'd prefer my
review before or after the next IETF.

Cheers,

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sun, 7 Oct 2012 02:11:32 +0000

> include the entire IPv6 header chain.

We don't necessarily know what a 'first-fragment' is in a given communications session, given unpredictability in order of arrival.  'Initial fragment' would probably be a better choice (vs. non-initial fragment).

;>

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton

---

From: Fernando Gont <[email-masked]>
Date: Sun, 07 Oct 2012 12:16:40 +0200

On 10/07/2012 04:11 AM, Dobbins, Roland wrote:
>> 2) It should probably reference
>> draft-ietf-6man-oversized-header-chain, since it means that you can
>> safely drop first-fragments that fail to include the entire IPv6
>> header chain.
> 
> We don't necessarily know what a 'first-fragment' is in a given
> communications session, given unpredictability in order of arrival.
> 'Initial fragment' would probably be a better choice (vs. non-initial
> fragment).

English as second language here, so the difference is not that big for
me. Anyway, I was referring to packets containing a Fragment Header with
the FO=0.

Cheers,

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sun, 7 Oct 2012 10:23:59 +0000

On Oct 7, 2012, at 5:16 PM, Fernando Gont wrote:

> English as second language here, so the difference is not that big for me.

No linguistic criticism intended, Fernando; in general, folks tend to refer to the 'first fragment', but there're really only initial fragments and non-initial fragments.  It's a small but important conceptual difference, IMHO, that's all.

		       -- John Milton

---

From: Fernando Gont <[email-masked]>
Date: Sun, 07 Oct 2012 12:35:18 +0200

On 10/07/2012 12:23 PM, Dobbins, Roland wrote:
> No linguistic criticism intended, Fernando; 

I was actually *encouraging* them :-), since I might use terms or
expressions that might sound incorrect to a native English-speaking person.

> in general, folks tend to
> refer to the 'first fragment', but there're really only initial
> fragments and non-initial fragments.

I guess the order (first, second, etc.) could refer to the order in
which the fragments are received, or the order that they "occupy" in the
original fragment?

e.g., it's easier to refer to each of the fragments in a, say,
four-fragment packet as "{first, second, third, fourth} fragment" as
oposed to....mm.. initial fragment, last fragment, and... what about the
two "middle" fragments?

P.S.: Discussion this one is important, since we're about to ship
draft-ietf-6man-ipv6-atomic-fragments...

Cheers,

---

From: "Dobbins, Roland" <[email-masked]>
Date: Sun, 7 Oct 2012 10:40:02 +0000

On Oct 7, 2012, at 5:35 PM, Fernando Gont wrote:

> e.g., it's easier to refer to each of the fragments in a, say, four-fragment packet as "{first, second, third, fourth} fragment" as
> oposed to....mm.. initial fragment, last fragment, and... what about the two "middle" fragments?

>From a purely network engineering standpoint, there are only initial fragments and non-initial fragments.  Apart from that distinction, ordering really only applies on the relevant endpoints.

		       -- John Milton

---

From: jouni korhonen <[email-masked]>
Date: Mon, 15 Oct 2012 23:02:39 +0300

Hi,

Two quick comments on Section 4.3 Lawful Intercept:

   In contrast, in mobile environments, since the 3GPP specifications
   allocate a /64 per device, it may be sufficient to intercept traffic
   from the /64 rather than specific /128's (since each time the device
   powers up it gets a new IID).

This is not entirely true anymore.. since Release-10 (don't hold your
breath when it gets deployed) a device may be delegated a shorter prefix
than /64. Also a cellular device may open multiple PDP Context/PDN
Connections thus a device may have multiple prefixes, not just one /64.

Second, the IID assertion is not correct either. A 3GPP device may use
as many IIDs during the lifetime of its PDP Context/PDN Connection as it
wishes for its non link-local addresses. Also, depending on the GGSN/PGW
implementation, the IID may never change for link-local addresses and can
be the same for all devices connected to it (some cellular hosts use that
IID also for their non link-local addresses).

- Jouni