Subject: [tsv-area] Comments on draft-blake-ipv6-flow-label-nonce-01

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 17 Nov 2008 07:29:04 -0600

I was interested to read this proposal, and have some comments regarding 
how I see UDP-Lite.  Since the draft assumes the flow-label is sent 
end-to-end unmodified, this could equally be included in the validity 
check for UDP-Lite (as you propose for TCP, UDP). The effect of this is 
the same for all transports - that is, if the label is corrupted, the 
packet is silently discarded.

I don't agree with the proposed method for UDP-Lite nin section 5. The 
checksum coverage field is use to indicate how much of the transport 
payload needs to be covered by the Integrity Check. It does not mean 
that other lower-layer (e.g. network) fields should be ignored.

I suggest that a UDP-Lite flow needs to decide whether it is concerned 
about off-path attacks.  If it wants to be robust to off-path attacks it 
SHOULD do the same as UDP. I think the same also applies to DCCP 
(section 7).

Best wishes,

Gorry Fairhurst

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Nov 2008 15:46:08 -0800

Some additional comments:

1) the flow label isn't covered by IPsec, TCP, or UDP checksums
	this should be noted, and implications if any

Gorry noted that if a flow label is modified, the packet should be
silently discarded, and was concerned about transports not checking
that. Neither UDP nor TCP checksums cover the IPv6 flow label, nor does
IPsec. The only check that can determine whether a flow label is valid
is inside the transport protocol. The key question is whether TCP or UDP
would have access to the flowID per se; there's no reason either
protocol should have full access to the network protocol header. I.e.,
this mod could require a substantial revision to stack code to
accommodate the layer violation herein.

The argument that UDP-Lite SHOULD NOT check the flow label, thus,
applies to UDP, TCP, and IPsec - i.e., if it's not valid for UDP-Lite
because of the lack of checksum coverage, why is it valid for TCP or UDP?

2) NAT interactions aren't discussed, e.g., NAT66
	there could be collisions or reuses that violate the
	requirements of this document that NATs don't correct for

3) the 'flow 0 means no flow' needs to be discussed
	i.e., when it says "not part of a flow", the doc should
	cite "i.e., when flowID == 0"

4) the doc should address whether flow 0 labels can be changed en-route
	it seems like using them as specified in this document
	requires that nodes MUST NOT change flowID 0 values

	(is this required by RFC3697, or does "set by the source"
	on page 2 imply nonzero?)

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Nov 2008 17:10:29 -0800

Steven Blake wrote:
> On Wed, 2008-11-19 at 15:46 -0800, Joe Touch wrote:
...
> I intend to add a section on NAT/locator translation; I wanted an
> opportunity to read the NAT66 draft before I did so (anti-spoofing
> protection in the presence of locator translation was what motivated me
> to write this draft).
> 
> Aside: NAT considerations in IPv6-related drafts have not been a
> requirement.  Is that going to change?

I don't think it's a requirement, but it seems relevant to at least
discuss. If you don't solve it, at least discuss the impact, IMO.

> NAT66 as specified in draft-mrw-behave-nat66-01 does not result in the
> case where two hosts behind the NAT would have their packet's source
> addresses translated into the same source address post-NAT (translation
> is 1:1 and stateless).  I assume that will be taken as a fundamental
> requirement for any NAT66 scheme.  With that assumption, it is preferred
> that the Flow Label not be modified.  This is a basic requirement of RFC
> 1883 and RFC 3697 (which obviously didn't anticipate NAT66 either).

It's worth noting then that:
	- if the NAT retains a unique source addr, then the flow label
	need not change, and SHOULD NOT change (?)
	- if the NAT merges traffic to come as if from a single address
	(e.g., to hide the number of hosts behind a NAT), then
	the flow label MAY be translated, but that the NAT MUST
	translate labels from colliding flows (to the same destination).

(I'm not positive that the above is your intent, but it's the basic idea
of what might be useful to address)

> Ok.
> That is correct; that is a basic requirement of RFC 1883 & RFC 3697.
> 
> My understanding is that it does not imply non-zero.

Thanks. I wasn't sure upon reading it.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Nov 2008 17:24:53 -0800

Steven Blake wrote:
> On Wed, 2008-11-19 at 17:10 -0800, Joe Touch wrote:
> 
>> Steven Blake wrote:
> Agreed
> I'm not sure that I am at liberty to suggest a violation of the rule
> that the flow label must remain unchanged (or at least I'm not sure that
> this is the right draft to do it in).  I was very careful to only
> tighten the SHOULDs in RFC 3697, and not violate any of the rules there,
> because I wanted the nonce application of the flow label to be able to
> be used simultaneously with any other application of it compliant with
> RFC 3697.  RFC 3697 obviously didn't anticipate NAT66.  There may be
> reasons why the rule is there that do not apply to the nonce
> application.

NATs tend to behave like a single host to the rest of the network. Rules
that apply to hosts apply to NATs as if they were the source of the
packet. In that sense, rewriting the labels consistently isn't any more
of a violation of the rules than rewriting the IP address is (which
isn't supposed to change either, FWIW).

Joe