Re: [shim6] APPSDIR review of draft-garcia-shim6-applicability-03

[Alberto García <[e-mail]>]

Hi Carsten,

Thank you very much for your review

 

|  -----Mensaje original-----

|  De: [e-mail] [mailto:[e-mail]] En nombre

|  de Carsten Bormann

|  Enviado el: miércoles, 29 de febrero de 2012 23:13

|  Para: IETF Apps Discuss;
<mailto:[e-mail]>
[e-mail];

|   <mailto:[e-mail]> [e-mail]

|  CC: The IESG

|  Asunto: [shim6] APPSDIR review of draft-garcia-shim6-applicability-03

|  

|  I have been selected as the Applications Area Directorate reviewer for
this

|  draft (for background on APPSDIR, please see

|
<http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate>
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

|  

|  Please resolve these comments along with any other Last Call comments

|  you may receive. Please wait for direction from your document shepherd or

|  AD before posting a new version of the draft.

|  

|  Gruesse, Carsten

|  ---------------------------------

|  

|  Document: draft-garcia-shim6-applicability-03.txt

|  Title: Applicability Statement for the Level 3 Multihoming Shim Protocol

|  (Shim6)

|  Reviewer: Carsten Bormann

|  IETF Last Call Date: 2012-02-15

|  Review Date: 2012-02-29

|  

|  ** Summary: This draft is ready for publication as an Informational

|     RFC with small changes, but maybe requires a better title.

|  

|  Note: I reviewed this with the expectation that the intended audience
will

|  read this *before* looking at RFC5533–5535 in detail.

|  

|  ** Major Issues:

|  

|  General:

|  

|  The document provides useful discussion of considerations around the

|  usage of Shim6.  At the end, it leaves the reader confused: What *is* the

|  applicability/area of application of Shim6?  

 

I assume this comment relates with the expectations created by the title, so
I comment below.

 

|  Who should decide whether

|  Shim6 is activated for a specific connection?  (There is an API in RFC
6316,

|  but clearly that is meant for advanced applications.) 

 

This issue was partially addressed in the 'Short-Lived Communications'
subsection. However, I think the text would improve by placing this in a
more prominent place, and by making a clearer statement. I have appended the
following text just to the end of the '2. Deployment Scenarios' section:

 

“To allow nodes to benefit from the capabilities provided by Shim6

   (discussed in Section 5) such as fault tolerance, nodes should be

   configured to initiate a Shim6 session with any peer node if they

   have multiple locators to use.  Note that this configuration can be

   performed transparently to the applications, in the sense that

   applications do not need to be aware of the Shim6 functionality

   provided by the node; iin particular, nodes are not forced to use the

   Shim6 API [RFC6316] to benefit from Shim6.  The Shim6 session should

   be created after the two nodes have been communicating for some time,

   i.e. using the deferred context establishment facility provided by

   Shim6.  Otherwise, the cost of the Shim6 4-way handshake used for

   establishing the session may exceed the benefits provided for short-

   lived communications (see Section 5.1.2).  More advanced node

   configuration may involved configuring different delays for

   initiating the session for different applications, for example, based

   on a per-port configuration.  Nodes being able to use a single

   locator for the communication should not initiate the creation of a

   Shim6 context, but should participate if other node initiates it.

   Note that Shim6-aware applications can overrid this behavior by means

   of the Shim6 API [RFC6316].”

 

By the way, I've also merged the 'Short-lived' and 'Long-lived' sections,
into a single '5.1.2. Short-lived and long-lived communications', which is
referred in the previous paragraph.

Does this address your concern?

 

|  While the document

|  successfully relates Shim6 to SCTP and HIP, what about other approaches
to

|  multi-addressing?  

In general, all mechanisms which handle different addresses at a higher
level than the network-layer may experience unwanted interactions with
Shim6. This applies to MPTCP, in addition to SCTP. Although there was a
generic comment regarding to this at the end of the SCTP section, I have
make this more explicit for MPTCP, by changing the SCTP section to refer to
both SCTP and MPTCP.

 

“7.3.  Shim6, SCTP and MPTCP
 
   Both the SCTP [RFC4960] and MPTCP [RFC6182] protocols provide a
   reliable, stream-based communications channel between two hosts which
   provides a superset of the capabilities of TCP.  One notable feature
   of these two protocols is that they allow the exchange of endpoint
   addresses between hosts, in order to recover from the failure of a
   particular endpoint pair, or to benefit from multipath communication
   in the MPTCP case, in a manner which is conceptually similar to
   locator selection in Shim6.
 
   SCTP and MPTCP are transport-layer protocols, higher in the protocol
   stack than Shim6, and hence there is no fundamental incompatibility
   which would prevent a Shim6-capable host from communicating using
   SCTP or MPTCP.
 
   However, since either SCTP or MPTCP, and Shim6 aim to exchange
   addressing information between hosts in order to meet the same
   generic goal, it is possible that their simultaneous use might result
   in unexpected behavior, e.g. lead to race conditions.
 
   The capabilities of these transport protocols with respect to path
   maintenance of a reliable, connection-oriented stream protocol are
   more extensive than the more general layer-3 locator agility provided
   by Shim6.  Therefore, it is recommended that Shim6 is not used for
   SCTP or MPTCP sessions, and that path maintenance is provided solely
   by SCTP or MPTCP.  There are at least two ways to enforce this
   behavior.  One option would be to make the stack, and in particular
   the Shim6 sublayer, aware of the use of SCTP or MPTCP and in this
   case refrain from creating a Shim6 context.  The other option is that
   the upper transport layer, informs using a Shim6-capable API like the
   one proposed in [RFC6316] that no Shim6 context must be created for
   this particular communication.
 
   In general, the issues described here may also arise for protocols
   which handle different addresses for two communicating nodes at a
   higher level than the network-layer to improve reliability,
   performance, congestion control, etc.”
 

 

|  When is happy-eyeballs enough?  

Umm. In my opinion, the happy-eyeballs algorithm is not related to Shim6.
Happy-eyeballs deals with dual-stack hosts connecting to servers. As
discussed in section ‘3.1 Protocol Version (IPv4 vs. IPv6)’, Shim6 is just
defined for IPv6.

 

 

|  When should MPTCP

|  be used?  

Now this is included in the new SCTP/MPTCP section commented before.

 

|  (The introduction to 7 then goes ahead and destroys any

|  remaining hope that this document provides the answers -- maybe this

|  should be split into "Open Issues" and the solid information about where

|  Shim6 is not needed.)

|  

|  The document may have started out as an applicability statement half a

|  decade ago, but maybe renaming it to "Considerations on the Application
of

|  Shim6" provides a more appropriate title now.

|  

|  Again, this is meant as a comment on the expectations raised by the title

|  and abstract, not as an attempt to belittle the usefulness of the
document's

|  content.

|  

 

I think I see your point. For me its ok to change the title to
‘Considerations on the Application of the Level 3 Multihoming Shim Protocol
(Shim6)’

I’ve also changed the abstract to a less ambitious

“This document discusses some considerations on the applicability of the
Shim6 IPv6 protocol and associated support protocols and mechanisms to
provide site multihoming capabilities in IPv6.”

 

Regarding to splitting section 7 into something like ‘open issues’, and ‘do
not mix’, this is not evident to me. The ‘do not mix’ is comprised of just
two subsections (‘SCTP/MPTCP’ and ‘HIP’). Besides, the ‘open issues’ part is
very heterogeneous: there are things we are pretty confident that should
work (e.g. ‘SEND and Shim6’), complex interactions (eg. NATs will work as
long as there are no changes in the locators, which leads to a functionality
which is not worse than current IPv6, although not as good as Shim6 could
provide…), things that may work but they should be tested (MIP, NEMO,
firewalls)…

I prefer the current approach in which each ‘Shim6 and other’ combination is
considered separately, without giving further structure to the section
(structure that is difficult for me to find).

 

|  ** Minor Issues:

|  

|  (1)

|  I'm not so fond of the DHCP speculation in 3.3.  An applicability
statement

|  should talk about what is, not what could be.  As of today, DHCP is not

|  applicable, and that should be clearly stated.  (Work in progress can, of

|  course, be pointed to, but it is not clear there is much more than a
problem

|  statement.)

 

OK. I’ve changed the section to this:

 

“3.3.  Address Generation and Configuration
 
   The security of the Shim6 protocol is based on the use of CGA and HBA
   addresses.
 
   CGA and HBA generation process can use the information provided by
   the stateless auto-configuration mechanism defined in [RFC4862] with
   the additional considerations presented in [RFC3972] and [RFC5535].
 
   Stateful address auto-configuration using DHCP [RFC3315] is not
   currently supported, because there is no defined mechanism to convey
   the CGA Parameter Data Structure and other relevant information from
   the DHCP server to the host.  An analysis of the possible
   interactions between DHCPv6 and Cryptographically Generated Addresses
   (CGAs) can be found in [I-D.ietf-csi-dhcpv6-cga-ps].”

 

 

|  

|  (2)

|  This sentence in 3.4 is opaque, unless it is talking about the state of

|  implementations (or is this another piece of DHCP speculation?):

|  

|             There is no current mechanism designed to allow an
administrator to

|             enforce the configuration of a CGA or an HBA in a host.

Ok, I’ve removed it, since the comment is implicit in the previous section. 

 

|  

|  (3)

|  Section 3.4, 7.2:  The term "hybrid" does not occur in RFC 5535.

|  Adapt the terminology.

OK, I adhere to RFC5535 text. Now the text says:

 

“ In the case that a Shim6-capable host is using HBAs to

  protect its locator sets, the host will need to generate

  an address which is both a valid CGA and a valid HBA, as defined in
[RFC5535]”

 

|  

|  (4)

|  Section 5.2:

|  

|             One such solution is being developed at the MP-TCP Working
Group.

|  

|  That is not the name of the WG, and referring to ephemeral IETF WGs is
not

|  very useful in an archival document such as an RFC.  It is probably most

|  appropriate to reference RFC 6182.

Done

 

|  

|  More generally speaking, one would expect some more guidance when

|  MPTCP is appropriate and when Shim6 is appropriate.  Oddly, RFC 6181

|  seems to provide more information about Shim6 on this point than the

|  present document.

Well, I think the inclusion of MPTCP along with SCTP provides much more
information. 

Regarding to the information included in RFC6181, this information has not
much to do with this ‘application’ document: RFC6181 describes the security
threats involving locator agility in MPTCP, which have some relation to
those faced by Shim6 (that’s why Shim6 is referred there). These threats are
related to the design of the protocol, but not to the application of the
protocol, since once they have been successfully addressed by the protocol
itself, the managers deploying it do not need to care about anymore. So
these issues are covered by the Shim6 specification [RFC5533], but do not
need to be considered here, in the applicability considerations.

 

|  

|  (5)

|  (On a related note, avoid discussion of the Shim6 WG's charter in 7.5.)

Sure. Changed to

“Shim6 aimed to provide a solution to …”

 

|  

|  ** Nits:

|  

|  [I-D.ietf-mif-problem-statement] is now RFC 6418.

|  

|  The document will benefit from some micro-editing, e.g.

|  s/different to/different from/g

|  s/specific of/specific to/g

|  s/associated to/associated with/g

|  s/is developed/has been developed/

|  The usage of "suffer" in several places

|  (in particular, should "These problems are suffered by other solutions

|              supporting multihoming such as SCTP [RFC4960] or HIP

|              [RFC4423]." in section 4 not be "relevant to" instead?)

|  "Shim6 has no means to enforce neither host nor network forwarding..."

Corrected to “When a locator has been selected by a host to be used as
source address for a Shim6 session, Shim6 has no means to enforce an
appropriate path for that source address neither in the host nor in the
network.”

 

|  "does not require also"

|  s/should be review/should be reviewed/

|  "...which security features can expect applications and users of the
Shim6

|  protocol."

|  As this is typically done by the RFC editor, I'm not providing a detailed
list

|  here.

|  

|  Section 4: s/not being used/not be used/

|  

|  Define "REAP" (I know, RFC5533 doesn't, either).

|  

|  Section 6: This sentence is hard to read:

|  "As long as the address exchanged, IP_A is the ULID..."

 

All these nits have been corrected.

 

Thanks again,

Alberto

 

|  

|  _______________________________________________

|  shim6 mailing list

|   <mailto:[e-mail]> [e-mail]

|   <https://www.ietf.org/mailman/listinfo/shim6>
https://www.ietf.org/mailman/listinfo/shim6