TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-multiaddressed-12

[Ballot discuss]
Updated based on -11:

I found this a well written and clear document - thanks.  Just a couple of points I'd like to discuss before changing my ballot position:

1) s3.1 contains the following:

If the listener acts in this way, however, it MUST generate
its key in a verifiable fashion, allowing it to verify that it
generated the key when it is echoed in the ACK.

What do mean by "in a verifiable fashion"?  Do you really mean reproducible?



We mean, "in a fashion by which the receiver could verify they were the generator". Specifying such a mechanism is far out of scope (it may not even be particularly possible), but this is part of the rationale for the ACK echoing keys to permit stateless operation, like SYN cookies today.





Two concerns:

1. I'm concerned that this is a MUST and there might not be a way to do it.  With SYN cookies, additional info is carried to allow the listener to figure out it was their key.  Where would the additional information be carried here?

2. You say it's stateless, but if an implementation does something like SYN cookies they've got to keep state.



2) Cleared - Addressed with new text added to the security considerations.

3) Cleared (no action required - exchange with author cleared this one up).

4) Cleared (no action required - exchange with author cleared this one up).

5) s3.1/s3.2: Hate that this uses SHA-1 for the IDSN and token, but I guess you're not really worried about collision resistance.  Is that true (gets a little bit at one of Stephen's)?  If it's true, you need to say something about not really needing that property of the hash algorithm in the security considerations.  Here's some text that's in a TLS WG draft that might be a good starting point:

The hash algorithm used in this specification
is required to have reasonable random properties
in order to provide reasonably unique identifiers.
There is no requirement that this hash algorithm
must have strong collision resistance.

I guess maybe just add:

The hash algorithm used in this specification to
generate the IDSN and token is …



For token, however, collisions would be a problem since the hash(key) = token, which is what is used to index the connection. Not a big deal on a small client, but I guess it might be an issue with servers with ~10k connections? Do you feel SHA-1 is inappropriate for this use?





If collisions are an issue then SHA-1 ought not be used see RFC 6194.

The other thing is once you deploy crypto trying to get rid of it is impossible.  If we can use SHA-256 instead now it will probably be better in the long run.



6) Cleared - draft -11 has text to address this one.

7) s3.5: Why are you returning the receiver's key in the MP_FASTCLOSE?  Couldn't you send something else back?  Also need to update the security considerations to mention that the receivers key is also returned in the MP_FASTCLOSE option.



my one concern here is that implementations will use the same key for every connection and it's a little linked to #2: Is this from s3.1:

The key MUST be hard to guess, and it MUST
be unique for the sending host at any one time.

trying to say a new key should be used on each connection?

[Ballot comment]

- Something wrong with this just before the start of 3.2, might need
an RFC editor note:

  "the IDSN of a MUST be the least significant 64 bits of the SHA-1 hash"

- Change on page 38, new text says;

  "Further security considerations around the issue of
  accidental or maliciously misdirecting ADD_ADDR messages are
  discussed in Section 5."

I think that'd be better as:

  "Further security considerations around the issue of
  accidentally mis-directed or maliciously directed ADD_ADDR
  messages are discussed in Section 5.

- This was a discuss point and I don't see a change for it, but
I'll let it go as a comment since its probably implied really.

Don't you need to say that a host MUST drop the
connection if it had set C=1 but receives a packet with a
missing checksum?

- And one old comment that also was once a discuss
and I guess you just don't wanna take on board;-)

What is the actual probability of a token collision in
3.1? I'm concerned it is not "very small" and most
especially for a server with many connections. Have you
done the math on this? According to [1] the probability is
about 10% of there being one collision with 25k
connections and hits 50% with 77163 connections. That is
not really "very small." And that ignores implemention
and/or RNG problems which are arguably more important.

Maybe just s/very/usually/

  [1] http://preshing.com/20110504/hash-collision-probabilities

[Ballot discuss]
Updated for -10. Thanks for adding the text on potential
future security - I've cleared discuss point #1.

I thought we'd had some mail on my other discuss points,
but I can't find that right now. I'll look to see if they're sorted
in -10 shortly. (In the hope that you find and re-tx the
mail first;-)

Thanks,
S


1. cleared

2. Split into remaining pieces:

  2.1 - Where does the current text make it clear that the hash and
          IDSN algs are tied to the crypto alg?

  2.2 - can a BadGuy to whom Alice connects use ADD_ADDR to
        DoS a possibly internal host on Alice's corporate n/w? What
        could be done about that.

3. Cleared

4. Don't you need to say that a host MUST drop the
connection if it had set C=1 but receives a packet with a
missing checksum?

[Ballot comment]

3. What is the actual probability of a token collision in
3.1? I'm concerned it is not "very small" and most
especially for a server with many connections. Have you
done the math on this? According to [1] the probability is
about 10% of there being one collision with 25k
connections and hits 50% with 77163 connections. That is
not really "very small." And that ignores implemention
and/or RNG problems which are arguably more important.

Maybe just s/very/usually/

  [1] http://preshing.com/20110504/hash-collision-probabilities

[Ballot comment]
Would it be difficult to add a short summary to this document calling out what information the mptcp implementation is expecting to get from the API?

[Ballot comment]
The authors have completely cleared up the description of the MP_CAPABLE flags, and the registry for them.  Thanks very much for working with me on this.

[Ballot discuss]

Updated for -10. Thanks for adding the text on potential
future security - I've cleared discuss point #1.

I thought we'd had some mail on my other discuss points,
but I can't find that right now. I'll look to see if they're sorted
in -10 shortly. (In the hope that you find and re-tx the
mail first;-)

Thanks,
S


1. cleared

2. Sending 64 bit keys in clear over the network with a
negotiation scheme that only allows 7 algorithms ever and
with sha-1 hard coded in various places == DISCUSS.  I
assume you anticipated this discuss;-) Probably the best
place to start is if you can send me a link to where this
cryptographic scheme was discussed in the wg archive, in
case questions I'd ask were already discussed. I have many
questions: for example, if a TCP option can handle 128
bits then why not use 128 bit keys in SYN and SYN/ACK and
just put the tokens in the ACK? Why not use some form of
Diffie-Hellman? Why hard-code sha-1 for token and IDSN
generation?  Why has ADD_ADDR no MAC?  etc etc. 
(Note; If we can sort point 1 this one will become much
easier, since the current experimental spec could then
be replaced with a better-security variant.)

3. What is the actual probability of a token collision in
3.1? I'm concerned it is not "very small" and most
especially for a server with many connections. Have you
done the math on this? According to [1] the probability is
about 10% of there being one collision with 25k
connections and hits 50% with 77163 connections. That is
not really "very small." And that ignores implemention
and/or RNG problems which are arguably more important. The
DISCUSS is: what are the consequences of a substantially
higher probability of token collisions for MPTCP?  (And
why not at least add some bits to that token?)

  [1] http://preshing.com/20110504/hash-collision-probabilities

4. Don't you need to say that a host MUST drop the
connection if it had set C=1 but receives a packet with a
missing checksum?

[Ballot comment]

Didn't check the comments for -10, so they may be out of
date.

- 1.1: surely the WG and not the authors imposed the
design constraints? If not, why not?

- 1.3: "Path" isn't an "MPTCP-specific term" its a term
used with a specific meaning by MPTCP. Same for others.

- 2.2: I hope those keys are what I think they are.  What
is MAC'd?

- 3: Just wondering. (And probably showing my ignorance;-)
Does that duplicate ACK interact in any way with conex or
ECN?

- 3.1: RFC 4086 gives recommendations for generating
random numbers, not random keys.

- 3.1: The key does not only have local meaning if its
used in two places, which it is.

- 3.2: Why has the attacker only one chance to guess the
MAC? I'm not sure that's true.

- Section 5: the "no worse" security requirement didn't
work out so well before, e.g. for WEP.

- Acks: I'd suggest you remove the EU liability disclaimer
since I'd not like to see that become common and I don't
think its really appropriate.

[Ballot comment]
This appears to me to be great work, and as an applications guy, I cannot wait for this to be deployed. The only thing that prevented me from balloting "Yes" instead of "No objection" is simply because much of the detailed technical work is beyond my knowledge base and I can't vouch for it personally. But what I do understand I'm very pleased by.

One addition that might serve folks well: You might add a section at the beginning or end of the document on open experimental issues that need to be addressed before going to standards track. In particular, 3.3.6, 3.3.7, and 3.8.2 point out such issues. I'm sure there are more. If you could summarize them in one section, it might be helpful.

[Ballot discuss]
I found this a well written and clear document - thanks.  Just a couple of points I'd like to discuss before changing my ballot position:

1) s3.1 contains the following:

If the listener acts in this way, however, it MUST generate
its key in a verifiable fashion, allowing it to verify that it
generated the key when it is echoed in the ACK.

What do mean by "in a verifiable fashion"?  Do you really mean reproducible?

2) I'm curious if the WG discussed not reusing the key for subsequent connections to the same host?

3) s3.1: (apologies if this is somewhere that I missed) Should you explicitly state that receiving an MP_CAPABLE option in anything other than the 1st subflow is an error and the such-and-such error code should be returned?

4) s3.1: Did the WG consider adding a nonce in the MP_CAPABLE option to protect against replay?

5) s3.1/s3.2: Hate that this uses SHA-1 for the IDSN and token, but I guess you're not really worried about collision resistance.  Is that true (gets a little bit at one of Stephen's)?  If it's true, you need to say something about not really needing that property of the hash algorithm in the security considerations.  Here's some text that's in a TLS WG draft that might be a good starting point:

The hash algorithm used in this specification
is required to have reasonable random properties
in order to provide reasonably unique identifiers.
There is no requirement that this hash algorithm
must have strong collision resistance.

I guess maybe just add:

The hash algorithm used in this specification to
generate the IDSN and token is …

6) s3.1: Instead of hardcoding the IDSN and token generation algorithm to SHA-1 could you hardcode it to whatever HMAC paired algorithm you use?  That way it's kind of like a suite of algs - S=1 and SHA-1 gets used for everything IDSN, token and MAC, S=2 SHA-256 gets used in those places and so on. 

I'm worried that in the future folks will need to string along SHA-1 when it's good and dead and we've all moved on to SHA-* (or whatever).  I can see some security auditor asking does you product use SHA-1; and I say why yes it does; and they say we can't buy your product or you fail this evaluation.

7) s3.5: Why are you returning the receiver's key in the MP_FASTCLOSE?  Couldn't you send something else back?  Also need to update the security considerations to mention that the receivers key is also returned in the MP_FASTCLOSE option.

[Ballot comment]
0) Fully support Stephen's discusses.

1) s2: r/standard/common ?

2) s3: MUST in the following? :

Those MPTCP options associated with subflow initiation must be
included on packets with the SYN flag set. 

3) s3.2: Probably worth adding another reference to [11] in the following paragraph:

The MP_JOIN SYN not only sends the token (which is static for a
connection) but also Random Numbers (nonces) that are used to prevent
replay attacks on the authentication method.

4) The reference for SHA-1 is normally:

  "Secure Hash Standard", United States of American,
  National Institute of Science and Technology, Federal
  Information Processing Standard (FIPS) 180-3,
  http://csrc.nist.gov/publications/fips/fips180-3/
  fips180-3_final.pdf.

and then you can provide an informative reference to RFC 6234 as a possible implementation.  Not everybody is going to use the code in 6234.

5) s3.2: Could you just use HMAC (hash-based message authentication code) instead of MAC in the text and in the figures?  I think it makes it much clearer and avoid the unnecessary indirection.

a) f6:

|              Sender's Truncated HMAC (64 bits)              |

b) f7: The MAC is HMAC-SHA1 right? so shouldn't the figure be:

|              Sender's MAC (160 bits HAMC-SHA1)              |

c) f8: I'd make it clear it's HMAC:

OLD:

  MAC-A = MAC(Key=(Key-A+Key-B), Msg=(R-A+R-B))
  MAC-B = MAC(Key=(Key-B+Key-A), Msg=(R-B+R-A))

NEW: add H

  MAC-A = HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B))
  MAC-B = HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A))

[Ballot comment]
As Pete noted:
The shepherd write-up is broken with respect to point (7). This should have been confirmed before submitting the draft to the IESG.

A comment where your response is requested:
Section 30, paragraph 6:
>    The value 0xf is reserved for Private Use.

  What is private use in your definition? In your testbed only or for
  your own protocol extension used on the public Internet? The first
  definition is Ok, with second some folks might step on other folks
  toes when running their code across the Internet at the same time.


Three comments for your considerations, but no need to respond to these:
Section 3.4.2., paragraph 3:

>    For security purposes, if a host receives a REMOVE_ADDR option, it
>    must ensure the affected path(s) are no longer in use before it
>    instigates closure.  The receipt of REMOVE_ADDR SHOULD first trigger
>    the sending of a TCP Keepalive [16] on the path, and if a response is
>    received the path SHOULD NOT be removed.  Typical TCP validity tests
>    on the subflow (e.g. ensuring sequence and ack numbers are correct)
>    MUST also be undertaken.

  Should such an event be logged? Looks like that something is going wrong.


Section 3.5., paragraph 9:

>    o  If host A does not receive a TCP RST in reply to its MP_FASTCLOSE
>      after one RTO (the RTO of the subflow where the MPTCP_RST has been
>      sent), it SHOULD retransmit the MP_FASTCLOSE.  The number of
>      retransmissions SHOULD be limited to avoid this connection from
>      being retained for a long time, but this limit is implementation-
>      specific.

  For the sake of the implementers: What is the guidance here on
  retransmissions?


Section 6., paragraph 15:

>    o  Traffic Normalizers [19] may not allow holes in sequence numbers,
>      and may cache packets and retransmit the same data.  MPTCP looks
>      like standard TCP on the wire, and will not retransmit different
>      data on the same subflow sequence number.  In the event of a
>      retransmission, he same data will be retransmitted on the original
>      TCP subflow even if it is additionally retransmitted at the

  s/he same data/the same data/

[Ballot discuss]
I have not completed my review of this document yet, but just starting my review, I discovered this in the shepherd writeup:


  (7) Has each author confirmed that any and all appropriate IPR
      disclosures required for full conformance with the provisions of BCP 78
      and BCP 79 have already been filed. If not, explain why.

  No.

That's very bad. If the authors have not confirmed, this document shouldn't even be in front of us yet. This is a shepherding failure. Please make sure that the authors have made all of their required disclosures and please reply before Thursday.

[Ballot comment]
I have several Comments that don't really merit a Discuss, but which you should really think about a little.

---

The description of Figure 13 could be clearer about the meaning of the
value n. I.e., there are n Address IDs present.

You should probably say whether n=0 is allowed.

Lastly, you should mark the unused bits on the figure as reserved.

---

In Figure 17, shouldn't the transition out of M_LAST-ACK (right-hand
side) be into M_TIME WAIT? Otherwise, the MPTCP PCB seems to not get
deleted.

---

Are you really happy with "RFC Required" as the allocation policy for
the new MPTCP Option Subtypes registry? You understand that one person
could write an Independent Stream RFC and take all of the available
code points in one go? Although you might hope that the IESG would spot
this and request the ISE to not publish the RFC, this seems like a risk.

Since the plan is to move to the Standards Track, why don't you change
this to "Standards Action"?

[Ballot discuss]
IANA had questions about the "MPTCP cryptographic handshake algorithms" registry that the authors did not answer, and which need to be answered.  I also have a question about it.

The IANA Considerations say this:

  This document also requests that IANA keeps a registry of "MPTCP
  cryptographic handshake algorithms" based on the flags in MP_CAPABLE
  (Section 3.1).
...
  Note that the length of this field is not fixed; it is a definition
  of the meaning of each bit in this field (i.e. 0x2, 0x4, 0x8, 0x10,
  etc).  Future specifications may define additional flags using the
  leftmost bits of this field, and therefore the number of bits
  available for cryptographic negotiation may change.

IANA's question, sent on 14 August, is this:

  Questions: Does this registry have a maximum value?  And if so,
  what is it?  Should value 0x0 be marked as 'Reserved'?

Part of the answer to the question is, of course, to explain bit fields: 0x0 is invalid, but also things like 0x3, 0x5, and 0x6 will not be registered at all, because they're combinations of bits.  Perhaps the document would be clearer to IANA if it referred to bits, perhaps this way:

  +-----------+----------------+----------------------------+
  | Flags    | Algorithm Name |          Reference        |
  +-----------+----------------+----------------------------+
  |  0000001  |    HMAC-SHA1  | This document, Section 3.2 |
  +-----------+----------------+----------------------------+

On the other hand, the notation you're using is understandable to us, so perhaps IANA doesn't need to understand it.

But the other part of the question, and the one I have a question about as well, is what it means to say that the length is not fixed.  It appears to be fixed at seven bits, of which one is already allocated.  How can more than six other bits be allocated?  I don't see any way to extend the bit field to create more bits.  Please explain.  And then please respond to IANA's message, so they can get the registry right.

Also also, should this second new registry also be a sub-registry of "TCP Parameters", as the first one (MPTCP option subtype values) is?  Right now, IANA plans to make it a new top-level registry.

[Ballot comment]

  This paragraph:
  >
  > MPTCP's interpretation of, and effect on, regular single-path TCP
  > semantics are discussed in Section 4.
  >
  seems to be out of place in the Terminology section.

[Ballot discuss]
It's easy to see that the mptcp implementation is expected to be able to send an address and optionally ports to the remote peer as part of an Add Address (3.4.1), but it's not clear whether the application gets to influence what that port is. The API document only talks about adding addresses (abstractly). Is it the intent to allow an application above the mptcp implementation to tell mptcp which local ports will work for each new interface added (which the app may have learned through interacting with a firewall control protocol for instance), and which should be used for a new subflow? If so, can the document please make it more obvious when/where this occurs?  Would it be difficult to add a short summary to this document calling out what information the mptcp implementation is expecting to get from the API?

Consider being more explicit about whether an mptcp connection can exist with no subflows. There is a requirement in 3.3.3 ("Essentially, a host MUST NOT close all functioning subflows unless it is safe to do so") that I think means no, but it's written in the context of closing the mtpcp connection. If an application removes all the available interfaces, should the connection continue to exist allowing a new subflow to be added later? Should the implementation return an error if the last interface for a connection is removed before closing it (or doing something else that would remove the last subflow)? Or should it complete a DATA_FIN sequence before removing the last subflow? Apologies if I missed where this is already described.

[Ballot discuss]


1. Separate from the details below, if MPTCP is a success
then it will be used for many years. However, the approach
taken seems to be limited to only ever supporting weak
security due to TCP option size restrictions and the fact
that you don't amortize any crypto parameters over more
than one packet. Attacker-capabilities will increase with
Moore's law so that just seems to be an insecure design
choice at quite a high level. Can you tell me either how
you could practically extend this design for stronger
cryptographic security or else why its ok for that to be
practically impossible?  TCP-MD5 should be a salutory
lesson here really.

2. Sending 64 bit keys in clear over the network with a
negotiation scheme that only allows 7 algorithms ever and
with sha-1 hard coded in various places == DISCUSS.  I
assume you anticipated this discuss;-) Probably the best
place to start is if you can send me a link to where this
cryptographic scheme was discussed in the wg archive, in
case questions I'd ask were already discussed. I have many
questions: for example, if a TCP option can handle 128
bits then why not use 128 bit keys in SYN and SYN/ACK and
just put the tokens in the ACK? Why not use some form of
Diffie-Hellman? Why hard-code sha-1 for token and IDSN
generation?  Why has ADD_ADDR no MAC?  etc etc. 
(Note; If we can sort point 1 this one will become much
easier, since the current experimental spec could then
be replaced with a better-security variant.)

3. What is the actual probability of a token collision in
3.1? I'm concerned it is not "very small" and most
especially for a server with many connections. Have you
done the math on this? According to [1] the probability is
about 10% of there being one collision with 25k
connections and hits 50% with 77163 connections. That is
not really "very small." And that ignores implemention
and/or RNG problems which are arguably more important. The
DISCUSS is: what are the consequences of a substantially
higher probability of token collisions for MPTCP?  (And
why not at least add some bits to that token?)

  [1] http://preshing.com/20110504/hash-collision-probabilities

3. Don't you need to say that a host MUST drop the
connection if it had set C=1 but receives a packet with a
missing checksum?

[Ballot comment]


- 1.1: surely the WG and not the authors imposed the
design constraints? If not, why not?

- 1.3: "Path" isn't an "MPTCP-specific term" its a term
used with a specific meaning by MPTCP. Same for others.

- 2.2: I hope those keys are what I think they are.  What
is MAC'd?

- 3: Just wondering. (And probably showing my ignorance;-)
Does that duplicate ACK interact in any way with conex or
ECN?

- 3.1: RFC 4086 gives recommendations for generating
random numbers, not random keys.

- 3.1: The key does not only have local meaning if its
used in two places, which it is.

- 3.2: Why has the attacker only one chance to guess the
MAC? I'm not sure that's true.

- Section 5: the "no worse" security requirement didn't
work out so well before, e.g. for WEP.

- Acks: I'd suggest you remove the EU liability disclaimer
since I'd not like to see that become common and I don't
think its really appropriate.

IANA has reviewed draft-ietf-mptcp-multiaddressed-09 and has  the following comments:

IANA has questions about an action related to IANA in this document.

IANA understands that, upon approval of this document, there are
three actions which IANA must complete.

Action 1:
IANA will update the following existing assignment in the TCP Option
Kind Numbers sub-registry of the TCP Parameters registry located at:

http://www.iana.org/assignments/tcp-parameters

as follows:

OLD:
Kind: 30
Length: -
Meaning: MPTCP
Reference: draft-ietf-mptcp-multiaddressed-07

NEW:
Kind: 30
Length: N
Meaning: Multipath TCP
Reference: draft-ietf-mptcp-multiaddressed-09

Action 2:
IANA will create a new sub-registry in the TCP Parameters registry
located at:

http://www.iana.org/assignments/tcp-parameters

This registry will be maintained via RFC Required as defined by RFC
5226.  Registrations in this new sub-registry will include
the following entries:

Sub-registry Name: MPTCP option subtype values
Reference: this document
Registration Requirement: RFC Required

  +--------------+----------------------------+---------------+-------+
  |    Symbol    |            Name            |  Reference  | Value |
  +--------------+----------------------------+---------------+-------+
  |  MP_CAPABLE  |      Multipath Capable    |  Section 3.1  |  0x0  |
  |    MP_JOIN  |      Join Connection      |  Section 3.2  |  0x1  |
  |      DSS    | Data Sequence Signal (Data |  Section 3.3  |  0x2  |
  |              |    ACK and Data Sequence  |              |      |
  |              |          Mapping)          |              |      |
  |  ADD_ADDR  |        Add Address        | Section 3.4.1 |  0x3  |
  |  REMOVE_ADDR |      Remove Address      | Section 3.4.2 |  0x4  |
  |    MP_PRIO  |  Change Subflow Priority  | Section 3.3.8 |  0x5  |
  |    MP_FAIL  |          Fallback          |  Section 3.6  |  0x6  |
  | MP_FASTCLOSE |        Fast Close        |  Section 3.5  |  0x7  |
  +--------------+----------------------------+---------------+-------+

The value 0xf is reserved for Private Use.  Values 0x8~0xe are available
for new assignments.

Action 3:
IANA is requested to create a new registry. The registry will be called
the "MPTCP cryptographic handshake algorithms".  Registrations in this
new registry will include the following entries:

Registry Name: MPTCP cryptographic handshake algorithms
Reference: this document
Registration Requirement: RFC Required
URL: http://www.iana.org/assignments/XXX

+-------+----------------+----------------------------+
| Flags | Algorithm Name |          Reference        |
+-------+----------------+----------------------------+
|  0x1  |    HMAC-SHA1  | This document, Section 3.2 |
+-------+----------------+----------------------------+

IANA Question: The document said "Note that the length of this field is
not fixed; it is a definition of the meaning of each bit in this field
(i.e. 0x2, 0x4, 0x8, 0x10, etc)."

Questions: Does this registry have a maximum value?  And if so, what
is it?  Should value 0x0 be marked as 'Reserved'?

Note:  The actions requested in this document will not be completed until
the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (TCP Extensions for Multipath Operation with Multiple Addresses) to Experimental RFC


The IESG has received a request from the Multipath TCP WG (mptcp) to
consider the following document:
- 'TCP Extensions for Multipath Operation with Multiple Addresses'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-08-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  TCP/IP communication is currently restricted to a single path per
  connection, yet multiple paths often exist between peers.  The
  simultaneous use of these multiple paths for a TCP/IP session would
  improve resource usage within the network, and thus improve user
  experience through higher throughput and improved resilience to
  network failure.

  Multipath TCP provides the ability to simultaneously use multiple
  paths between peers.  This document presents a set of extensions to
  traditional TCP to support multipath operation.  The protocol offers
  the same type of service to applications as TCP (i.e. reliable
  bytestream), and provides the components necessary to establish and
  use multiple TCP flows across potentially disjoint paths.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1842/
  http://datatracker.ietf.org/ipr/1843/

UPDATE to Shepherd Writeup:

Based on one WG-participant's assertion during a meeting and on the mailing list that certain patents from other companies are related to MPTCP, two 3rd-party IPR disclosures have been filed.  Neither when this came up during a meeting, nor during mailing list discussion was there any concern expressed from the working group about continuing with the existing specification and design work.

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?  Why
    is this the proper type of RFC?  Is this type of RFC indicated in the
    title page header?

This draft describes the specification of Multipath TCP that is a set of new extensions
of TCP and it is intended to be an Experimental RFC as described in the title
page header.
I believe an experimental is the proper type of RFC as we need broader experiments
for this specification.


(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up. Recent
    examples can be found in the "Action" announcements for approved
    documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This draft describes the specification of Multipath TCP that is a set of new
extension of TCP. Multipath TCP is designed to provides the ability to
simultaneously use multiple paths between peers.
This document presents message formats of Multipath TCP extensions and
their interactions as well as the operational overviews and brief introduction.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

This draft has been discussed for two years in the WG and there has been
no major controversial points.
There is a strong consensus in the WG for publication as we already have
several implantation activities.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?


This document has been reviewed by various people.
Several implementation projects have already started based on this and
detailed comments from the implementors contributed a lot to improve
the quality of the draft.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area Director?

Yoshifumi Nishida is the Document Shepherd for this document.
The Responsible Area Director is Wesley Eddy.


(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.  If this version of the document is not ready
    for publication, please explain why the document is being forwarded to
    the IESG.

I've made several clarification suggestions in order to enhance the
readability of the drafts and the draft has already been updated.
I believe the quality of this draft is matured enough to be published.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed? 

I have no concern about it.


(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA, DNS,
    DHCP, XML, or internationalization? If so, describe the review that
    took place.


I believe that there is no need for particular reviews.


(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or the
    IESG should be aware of? For example, perhaps he or she is uncomfortable
    with certain parts of the document, or has concerns whether there really
    is a need for it. In any event, if the WG has discussed those issues and
    has indicated that it still wishes to advance the document, detail those
    concerns here.

I have no concerns with the document.


(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP 78
    and BCP 79 have already been filed. If not, explain why.

No.


(8) Has an IPR disclosure been filed that references this document?
    If so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

No.


(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it? 

I believe there is strong consensus on this draft and it is widely understood
and supported as we have seen positive comments from various participants
in the WG meetings and implementors.


(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict in separate
    email messages to the Responsible Area Director. (It should be in a
    separate email because this questionnaire is publicly available.)

No one has indicated discontent.


(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
    Checklist). Boilerplate checks are not enough; this check needs to be
    thorough.

This document is verified with idnits 2.12.13.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

I believe no formal review is needed.

(13) Have all references within this document been identified as
    either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such normative
    references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director in the
    Last Call procedure.

No.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header, listed
    in the abstract, and discussed in the introduction? If the RFCs are not
    listed in the Abstract and Introduction, explain why, and point to the
    part of the document where the relationship of this document to the
    other RFCs is discussed. If this information is not in the document,
    explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of the
    document. Confirm that all protocol extensions that the document makes
    are associated with the appropriate reservations in IANA registries.
    Confirm that any referenced IANA registries have been clearly
    identified. Confirm that newly created IANA registries include a
    detailed specification of the initial contents for the registry, that
    allocations procedures for future registrations are defined, and a
    reasonable name for the new registry has been suggested (see RFC 5226).

I've confirmed there is no consistency problem.
I believe the IANA considerations section of this draft satisfies the guidelines
described in RFC5226.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

I believe there is no need to require expert review for future allocations.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

The document contains no formal language.