Early Review of draft-ietf-mptcp-rfc6824bis-11
review-ietf-mptcp-rfc6824bis-11-secdir-early-eastlake-2018-07-19-00
| Request |
Review of |
draft-ietf-mptcp-rfc6824bis
|
|
Requested rev. |
no specific revision
(document currently at 13)
|
|
Type |
Early Review |
|
Team |
Security Area Directorate
(secdir)
|
|
Deadline |
2018-06-30
|
|
Requested |
2018-06-05 |
|
Requested by |
Philip Eardley |
|
Other Reviews |
|
|
Comments |
We've just started a WG last call on draft-ietf-mptcp-rfc6824bis. It would be great to have an early Security Area review, to allow any issues to be discussed prior to /at Montreal. Thank-you!
Here's the WGLC text:
<<This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send comments by the end of June.
Please note there are three IPR disclosures (we're working on getting them added to the rfc6824bis page):
* two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mptcp-multiaddressed
* one is inherited from draft-paasch-mptcp-syncookies (which got include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/
>>
|
| Review |
State |
Completed
|
|
Reviewer |
Donald Eastlake
|
|
Review |
review-ietf-mptcp-rfc6824bis-11-secdir-early-eastlake-2018-07-19
|
|
Posted at |
https://mailarchive.ietf.org/arch/msg/secdir/RwQqGewdo9Rf5_YRS3KyEUIaa6Y
|
|
Reviewed rev. |
11 (document currently at 13) |
|
Review result |
Ready |
|
Draft last updated |
2018-07-19 |
|
Review completed: |
2018-07-19
|
Review
review-ietf-mptcp-rfc6824bis-11-secdir-early-eastlake-2018-07-19
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the
IESG. Document editors and WG chairs should treat these comments just like
any other last call comments.
The summary of the review is Ready.
This draft specified version 1 of Multipath TCP obsoleting version 0. The
paths are identified by the 4-tuple of IP addresses and ports for each
path. The services offered to applications are the same as TCP. The
additional information needed for setting up and tearing down paths,
synchronizing flows, etc., is communicated using TCP options.
The Security Considerations section appears to be good and the security
mechanisms adequate to achieve the documents goal of being as secure as
TCP. There is a good if somewhat generalized Threat Analysis in RFC 6181 as
well as an Architecture document in RFC 6182 that considers security
aspects.
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
1424 Pro Shop Court, Davenport, FL 33896 USA
d3e3e3@gmail.com