Subject: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 18 Nov 2009 07:56:46 -0800

Folks,

As stated during the meeting, we're starting a two weeks WGLC on our "Traffic Selectors for Flow Bindings" document, available at the following URL:

<http://tools.ietf.org/wg/mext/draft-ietf-mext-binary-ts-01>

Please review the specification, post your comments to the mailing list, and state whether or not you think the document is ready to be forwarded to IESG before 2009-12-02 6:00PM PST.
 
Thank you for your support.
 
--julien & marcelo, MEXT chairs

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 18 Nov 2009 10:12:43 -0800

Someone pointed out that I sent a broken URL for the draft, sorry about that. The correct URL is:

<http://tools.ietf.org/html/draft-ietf-mext-binary-ts-01>

--julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Laganier, Julien
> Sent: Wednesday, November 18, 2009 7:57 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MEXT] [WGLC] draft-ietf-mext-binary-ts-01
> 
> Folks,
> 
> As stated during the meeting, we're starting a two weeks WGLC on our
> "Traffic Selectors for Flow Bindings" document, available at the
> following URL:
> 
> Please review the specification, post your comments to the mailing list,
> and state whether or not you think the document is ready to be
> forwarded to IESG before 2009-12-02 6:00PM PST.
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: Benjamin Lim <[email-masked]>
Date: Mon, 30 Nov 2009 14:03:17 +0800

Hi,

I have reviewed the draft and have some questions/editorials stated below.

Regards,
Benjamin Lim

-----------
> Abstract
> 
> This document defines binary formats for IPv4 and IPv6 traffic 
> selectors to be used in conjuction with flow bindings for Mobile
[Ben] s/ conjuction/ conjunction

> IPv6.

...

> 2.  Introduction
> 
> This document defines binary formats for IPv4 and IPv6 Traffic 
> Selector sub-options as defined in [I-D.ietf-mext-flow-binding].
> 
> The binary traffic selector sub-options defined here, allow efficient
>  identification of flow(s) based on well known fields in IPv4 
> [RFC0791], IPv6 [RFC2460], and transport layer headers like TCP 
> [RFC0793] and UDP [RFC0768].

[Ben] Propose to rephrase to "The binary traffic selector sub-options
defined here, allow for efficient..."

...

> 3.1.  IPv4 binary traffic selector

...

> 
> (B)End Source Address
> 
> If more than one contiguous source addresses need to be mached
[Ben] s/ mached/ matched

> then this field can be used to indicate the end value of a range 
> starting from the value of the Start Source Address field.  This 
> field MUST NOT be included unless the Start Source Address field is
> included.  When this field is included the receiver will match all of
> the addresses between fields (A) and (B), inclusive of (A) and (B).

[Ben] For clarification, if it is only to match one IP address of CN,
does it mean that "(A)Start Source Address" and "(B)End Source Address"
would be of the same IP address? The same question applies to those
fields that allow specifying ranges.

...
> 
> (D)End Destination Address
> 
> If more than one contiguous destination addresses need to be mached
[Ben] s/ mached/ matched

> then this field can be used to indicate the end value of a
> range starting from the value of the Start Destination Address field.
> This field MUST NOT be included unless the Start Destination Address
> field is included.  When this field is included the receiver will
> match all of the addresses between fields (C) and (D), inclusive of
> (C) and (D).

...

> (F)End SPI - Security Parameter Index
> 
> If more than one contiguous SPI values need to be mached then this
[Ben] s/ mached/ matched

> field can be used to indicate the end value of a range starting from
> the value of the Start SPI field.  This field MUST NOT be included
> unless the Start SPI field is included.  When this field is included
> the receiver will match all of the SPI values between fields (E) and
> (F), inclusive of (E) and (F).

...

> (H)End Source Port
> 
> If more than one contiguous source port numbers need to be mached
[Ben] s/ mached/ matched

> then this field can be used to indicate the end value of a range 
> starting from the value of the Start Source Port field.  This field
> MUST NOT be included unless the Start Source Port field is included.
> When this field is included the receiver will match all of the port
> numbers between fields (G) and (H), inclusive of (G) and (H).

...

> (J)End Destination Port
> 
> If more than one contiguous destination port numbers need to be 
> mached then this field can be used to indicate the end value of a
[Ben] s/ mached/ matched

> range starting from the value of the Start Destination Port field. 
> This field MUST NOT be included unless the Start Destination Port 
> field is included.  When this field is included the receiver will 
> match all of the port numbers between fields (I) and (K),
[Ben] s/ (K)/ (J)

> inclusive of (I) and (J).
> 
> (K)Start DS - Differential Services
> 
> This field identifies the first differential services value, from the
> range of differential services values to be matched, on data packets
> as seen by the home agent.  Note that this field is called Type of
> Service field in [RFC0791].  [RFC3260] then clarified that the field
> has been redefined as 6 bits DS field and 2 bits reserved, later
> claimed by Explicit Congestion Notification (ECN) [RFC3168].  For the
> purpose of this specification the DS field is 8bit long, were the 6
[Ben] s/ 8bit/ 8 bits

> most significant bits indicating the DS
> field to be matched and the 2 list significant bits MUST be set to 0
> by the sender and ignored by the receiver.
> 
> (L)End DS - Differential Services
> 
> If more than one contiguous DS values need to be mached then this
[Ben] s/ mached/ matched

> field can be used to indicate the end value of a range starting from
> the value of the Start DS field.  This field MUST NOT be included
> unless the Start DS field is included.  When this field is included
> the receiver will match all of the values between fields (K) and (L),
> inclusive of (K) and (L).

[Ben] I assume that same note for (K) on how to format the bits in the
DS field applies to (L) also? I.e. For the purpose of this specification
the DS field is 8 bits long, were the 6 most significant bits indicating
the DS field to be matched and the 2 list significant bits MUST be set
to 0 by the sender and ignored by the receiver.

...

> (N)End Protocol
> 
> If more than one contiguous protocol values need to be mached then
[Ben] s/ mached/ matched

> this field can be used to indicate the end value of a range starting
> from the value of the Start Protocol field.  This field MUST NOT be
> included unless the Start Protocol field is included. When this field
> is included the receiver will match all of the values between fields
> (M) and (N), inclusive of (M) and (N).

[Ben] For my understanding, can I ask what is the purpose of the
"Protocol field"?

...

> 3.2.  IPv6 binary traffic selector

...

> (B)End Source Address
> 
> If more than one contiguous source addresses need to be mached
[Ben] s/ mached/ matched

> then this field can be used to indicate the end value of a range 
> starting from the value of the Start Source Address field.  This 
> field MUST NOT be included unless the Start Source Address field is
> included.  When this field is included the receiver will match all of
> the addresses between fields (A) and (B), inclusive of (A) and (B).

...

> (D)End Destination Address
> 
> If more than one contiguous destination addresses need to be mached
[Ben] s/ mached/ matched

> then this field can be used to indicate the end value of a
> range starting from the value of the Start Destination Address field.
> This field MUST NOT be included unless the Start Destination Address
> field is included.  When this field is included the receiver will
> match all of the addresses between fields (C) and (D), inclusive of
> (C) and (D).

...

> (F)End SPI - Security Parameter Index
> 
> If more than one contiguous SPI values need to be mached then this
[Ben] s/ mached/ matched

> field can be used to indicate the end value of a range starting from
> the value of the Start SPI field.  This field MUST NOT be included
> unless the Start SPI field is included.  When this field is included
> the receiver will match all of the SPI values between fields (E) and
> (F), inclusive of (E) and (F).

...

> (G)Start Flow Label
> 
> This field identifies the first flow label value, from the range of
> flow label values to be matched, on data packets as seen by the home
> agent.  According to [RFC2460] the flow label is 24-bit long. For the
> purpose of this specification the sender of this options MUST prefix
> flow label values with 8-bits of "0" before inserting it in this
> field.
[Ben] Reword the above sentence to "For the purpose of this
specification the sender of this option MUST prefix the flow label
values with 8-bits of "0" before inserting it into this field."

> The receive SHOULD ignore the first 8-bits of
[Ben] s/ receive/ receiver

> this field.
> 
> (H)End Flow Label
> 
> If more than one contiguous flow label values need to be mached
[Ben] s/ mached/ matched

> then this field can be used to indicate the end value of a range 
> starting from the value of the Start Flow Label field.  This field 
> MUST NOT be included unless the Start Flow Label field is included.
> When this field is included the receiver will match all of the flow
> label values between fields (G) and (H), inclusive of (G) and (H).

...

> (J)End Source Port
> 
> If more than one contiguous source port numbers need to be mached
[Ben] s/ mached/ matched

> then this field can be used to indicate the end value of a range 
> starting from the value of the Start Source Port field.  This field
> MUST NOT be included unless the Start Source Port field is included.
> When this field is included the receiver will match all of the port
> numbers between fields (I) and (J), inclusive of (I) and (J).

...

> (L)End Destination Port
> 
> If more than one contiguous destination port numbers need to be 
> mached then this field can be used to indicate the end value of a
[Ben] s/ mached/ matched

> range starting from the value of the Start Destination Port field. 
> This field MUST NOT be included unless the Start Destination Port 
> field is included.  When this field is included the receiver will 
> match all of the port numbers between fields (K) and (L), inclusive
> of (K) and (L).
> 
> (M)Start DS - Differential Services
> 
> This field identifies the first differential services value, from the
> range of differential services values to be matched, on data packets
> as seen by the home agent.  Note that this field is called Type of
> Service field in [RFC0791].  [RFC3260] then clarified that the field
> has been redefined as 6 bits DS field and 2 bits reserved, later
> claimed by Explicit Congestion Notification (ECN) [RFC3168].  For the
> purpose of this specification the DS field is 8bit long, were the 6
[Ben] s/ 8bit/ 8 bits

> most significant bits indicating the DS
> field to be matched and the 2 list significant bits MUST be set to 0
> by the sender and ignored by the receiver.
> 
> (N)End DS - Differential Services
> 
> If more than one contiguous DS values need to be mached then this
[Ben] s/ mached/ matched

> field can be used to indicate the end value of a range starting from
> the value of the Start DS field.  This field MUST NOT be included
> unless the Start DS field is included.  When this field is included
> the receiver will match all of the values between fields (M) and (N),
> inclusive of (M) and (N).

[Ben] I assume that same note for (M) on how to format the bits in the
DS field applies to (N) also? I.e. For the purpose of this specification
the DS field is 8 bits long, were the 6 most significant bits indicating
the DS field to be matched and the 2 list significant bits MUST be set
to 0 by the sender and ignored by the receiver.

...

> (P)End NH - Next Header
> 
> If more than one contiguous next header values need to be mached
[Ben] s/ mached/ matched

> then this field can be used to indicate the end value of a range 
> starting from the value of the Start NH field.  This field MUST NOT
> be included unless the Start next header field is included. When this
> field is included the receiver will match all of the values between
> fields (O) and (P), inclusive of (O) and (P).

...

> 4.  Security Considerations
> 
> This draft defines the format of traffic selector sub-options defined
>  in the flow bindings [I-D.ietf-mext-flow-binding].  The authors have
>  not identified any security concenrs pertaining to this draft beyond
[Ben] s/ concenrs/ concerns

> what is already identified in [I-D.ietf-mext-flow-binding].

...

> 6.  Aknowledgements
[Ben] s/ Aknowledgements/ Acknowledgements

> 
> The authors would like to thank Patrick Stupar and Julien Laganier 
> for their contributions to this document.

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 30 Nov 2009 13:44:16 -0800

Folks -

This is my hat-less draft review:

I think the draft is ready provided that the minor points below are addressed:

1- We should include the following alignments requirements for the sub-options: 

* IPv4 TS:
- 4n aligned if A, B, C, D, E or F is set
- 2n aligned if G, H, I or J is set
- n aligned otherwise

* IPv6 TS:
- 8n aligned if A, B, C, or D is set
- 4n aligned if E, F, G, or H is set
- 2n aligned if I, J, K, or L is set
- n aligned otherwise

2- I feel that the text describing the Start/End field for ranges could be made simpler by formulating a la RFC 4306 (IKEv2), as per this template:

* Start <Xyz>(<v>) - Value specifying the smallest <Xyz>
      allowed by this Traffic Selector. If the End <Xyz> field
      is not included, this is the only <Xyz> allowed by this 
      Traffic Selector.

* End <Xyz>(<w>) - Value specifying the largest <Xyz>
      allowed by this Traffic Selector. This field MUST NOT 
      be included unless the Start <Xyz> field is included. 

Thanks,

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 30 Nov 2009 13:48:24 -0800

This is a reminder that there are only two days left to review this draft as part of the WGLC. 

--julien

---

From: Dave Craig <[email-masked]>
Date: Mon, 30 Nov 2009 16:48:03 -0800

3. page 5.  How about specifying 0x1 for IPv4 traffic selector and 0x2
for IPv6 traffic selector?

3.1. page 6, How about adding the following to the end of the SPI
field descriptions (EF), "A present SPI field does not match traffic
without an IPsec header."  Also applies to 3.2. page 10.

3.1. page 7, How about adding the following to the end of the port
field description (GHIJ), "A present port field does not match traffic
with IP protocols that do not define a transport port."  Also add a
reference to the port number definitions, so it is not ambiguous which
port you're talking about.
http://www.iana.org/assignments/port-numbers.

3.2. page 12 (OP), Suggest making the next header match against any of
the IPv6 next headers.  This would enable a filter to match against a
jumbo payload that might be behind a router alert.  New text might
read, "This field identifies the first 8-bit next header value" of any
of the next headers in the packet, "from the..."

3.2.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved     |             (G)Start Flow Label             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved     |             (H)End Flow Label               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

probably should update the block for DS, too.

3.2.

For the purpose of this specification, the sender of this option
     MUST prefix flow label values with 8-bits of "0" before inserting
     it in this field.

s/mached/matched/

s/2 list significant/2 least significant/

3.2(M) /3.1(K)

For the purpose of this specification the DS field is
      8 bits long, where the 6 most...

Hope this helps,
Dave

---

From: Dave Craig <[email-masked]>
Date: Mon, 30 Nov 2009 17:18:03 -0800

> fields that allow specifying ranges.

[Dave] I believe you may have found a way to half the number of flags
and eliminate incorrectly formatted messages.  What about coalescing
start and end flags into a single flag that specifies whether both
fields are valid?

Scenario 1: no range specified
* Single flag approach, flag for start&end unset
* Start/end flag approach start/stop flags unset

Scenario 2: single match value specified
* Single flag approach, flag for start&end set, start value == end
value == match value
* Double flag approach, flag for start set, start set to match value

Scenario 3: range specified
* Single flag approach, flag for start&end set, start and end field
values independently set
* Double flag approach, flag for start and end set, start and end
field values independently set

Hope this helps,
Dave

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 30 Nov 2009 17:18:24 -0800

Dave Craig wrote:
> [...]

Would it be simpler to say "this field MUST NOT be present if the protocol is neither IPsec AH nor ESP"?
 
> http://www.iana.org/assignments/port-numbers.

I am not sure we want to cite the port-numbers registry. This seems to imply that only the ports as registered in the registry are legal in terms of this specification, and I'm not sure we want that...

As to restricting the port field to protocols defining a transport port, I'm wondering whether we want to have a provision similar to that of RFC 4306 (IKEv2) w.r.t. ICMP:

   For the ICMP protocol, the two one-octet fields Type and Code are treated
   as a single 16-bit integer (with Type in the most significant eight bits
   and Code in the least significant eight bits) port number for the purposes
   of filtering based on this field.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 30 Nov 2009 17:24:18 -0800

> >> included.  When this field is included the receiver will match all
> >> of the addresses between fields (A) and (B), inclusive of (A) and 
> >> (B).
> >
> > does it mean that "(A)Start Source Address" and "(B)End Source
> > Address" would be of the same IP address? The same question applies 
> > to those fields that allow specifying ranges.
> >
> > ...
> 

This is what I had in mind (i.e., single flag for both start & end fields) when I originally proposed to encode ranges instead of single values in the traffic selectors as IKEv2 does. The current design with separate start & end flags allows for smaller traffic selectors when single values are encoded, at the price of double the number of flags. It seemed like a good trade-off.

--julien

---

From: Dave Craig <[email-masked]>
Date: Mon, 30 Nov 2009 18:07:10 -0800

> Would it be simpler to say "this field MUST NOT be present if the protocol is neither IPsec AH nor ESP"?

Both solutions would work, but is there a reason to add more
verification logic and possible causes for failure messages in the
protocol?

>   of filtering based on this field.

Which fields would you use for a GRE packet when the filter only
specifies ports?  Suggest paring down the problem to match only
specified protocol where you know the mapping, then.  IPv6 NH also
matches ICMPv6 type+code.  IPv4 protocol also matches ICMP type +
code.

---

From: Dave Craig <[email-masked]>
Date: Mon, 30 Nov 2009 18:11:04 -0800

> This is what I had in mind (i.e., single flag for both start & end fields) when I originally proposed to encode ranges instead of single values in the traffic selectors as IKEv2 does. The current d…

I misinterpreted "present" as "valid".  Ok

Dave