Re: [shim6] WG Last Call for draft-ietf-shim6-multihome-shim-api

[Shinta Sugimoto <[e-mail]>]

Hi Brian,

Thank you very much for your comments. Please find my comments inline.

Let me address my opinion on compatibility issue of SHIM/HIP and SCTP/multi-path TCP in another threads. 

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]] 
> Sent: Sunday, December 13, 2009 5:24 AM
> To: [e-mail]
> Cc: Kristian Slavov; [e-mail]; Shinta Sugimoto
> Subject: Re: [shim6] WG Last Call for 
> draft-ietf-shim6-multihome-shim-api
> 
> Hi,
> 
> First a confession, I have never seriously looked at the 
> earlier versions, so I apologise if I am covering old ground.
> 
> Basically this looks good to me, but I think it isn't quite ready.
> 
> I don't really like the first three paragraphs of the Introduction.
> The tone is almost apologetic somehow. Could we be more 
> clear, really just by starting something like
> 
>   This document defines socket API extensions by which upper layer
>   protocols may be informed about and control the way in which
>   multihoming shims in the IP layer manage the dynamic choice of
>   locators. Initially it applies to SHIM6 and HIP, but it is defined
>   generically.
> 
> and then present the main features of the shims and loc-id separation.
> (Also see my later comment about the Conclusion section.)

Ok, let us revise the text as you suggeted.  BTW, the intention of the three paragraphs in the
currerent text is to provide explanation to people who ask "HIP/SHIM6 aims at
hiding locators from applications, doesn't it? Then why you specify something
which requires applications to deal with locators?"  But I guess texts were not so clear.

> Also in the Introduction
> 
> >    This document recommends that the switching of 
> identifier and locator
> >    is done only once inside the TCP/IP stack of an endhost. 
>  That is, if
> >    multiple shim sub-layers exist at the IP layer, any one of them
> >    should be applied exclusively for a given flow.
> 
> I agree with this, but does it really belong in the API spec? 
> It seems more like something for an applicability statement. 
> However, if this stays, I think it should be very explicit, 
> adding something like:

I agree that this is a generic issue in SHIM6/HIP and it is more like applicability statement.
Let us revise the text.

>   Specifically, only one of SHIM6 and HIP should be in use, 
> and neither
>   of them are compatible with SCTP or multipath TCP.
> 
> (see 
> http://www.ietf.org/mail-archive/web/multipathtcp/current/msg0
> 0178.html
> for example)

Let me comment in different thread about compatibility issue.

> > 2.  Terminology
> ...
> >    o  Endpoint identifier (EID) - The identifier used by 
> the application
> >       to specify the endpoint of a given communication.  
> Applications
> >       may handle EIDs in various ways such as long-lived 
> connections,
> >       callbacks, and referrals[I-D.ietf-shim6-app-refer].
> >       *  In the case of SHIM6, an identifier called a ULID 
> serves as an
> >          EID.  A ULID is chosen from locators available on the host.
> >       *  In the case of HIP, an identifier called a Host Identifier
> >          serves as an EID.  A Host Identifier is derived 
> from the public
> >          key of a given host.  For the sake of backward 
> compatibility
> >          with the sockets API, the Host Identifier is 
> represented in a
> >          form of hash of public key.
> 
> We might add a clarification that the EID appears in the 
> standard socket API as an address, and does not appear in the 
> extensions defined in this document, which only concern locators.

I agree. Let us add this note in the explanation about EID.

> > 4.  Requirements
> ...
> >    o  Turn on/off shim.  An application should be able to request to
> >       turn on or turn off the multihoming support by the shim layer:
> >       *  Apply shim.  The application should be able to explicitly
> >          request the shim sub-layer to apply multihoming support.
> >       *  Don't apply shim.  The application should be able 
> to request
> >          the shim sub-layer not to apply the multihoming 
> support but to
> >          apply normal IP processing at the IP layer.
> 
> We might add a note that this function is also required by 
> any multipath transport layer such as SCTP or MPTCP, with the 
> details being operating system dependent.

I think this relates to the compabilitiy issue, so let me state my view in differnet thread.

> > 11.  Discussion
> > 
> >    In this section, open issues are introduced.
> 
> This section is non-normative. I think it should be an appendix.

Ok.

> > 12.  Changes
> 
> This section seems to be in a strange place, but in any case 
> it should be marked for deletion by the RFC Editor.

Ok.

> > 14.  Security Considerations
> 
> It seems to me that the Unknown Locator mechanism described 
> in section 11.4 might act as a bypass for the security 
> mechanism applied by the shim.

Let me clarify if I undertand your comment.
Yes, application may provide locator(s) which the multihome shim sub-layer
may not be aware of.  In principle, the reaction of the multihome shim sub-layer
must be aligned with what is stated in Section 7.2 (Locator Verification) of
RFC 5533.  Besides, I think an error message must be returned to the application
when it tries to use unknown locator as the source address for outbound user traffic.
Does this cover your concern?

> > 15.  Conclusion
> 
> We don't normally put conclusions in RFCs. Actually, the 
> content seems to belong in the Introduction.

Ok.

> > Appendix A.  Context Forking
> ...
> >    Another viable approach is to extend SHIM6 protocol by adding
> >    capability of exchanging additional information to identify the
> >    packet flow from others which needs to be handled by a 
> newly forked
> >    context.  The information exchange can be done during the context
> >    establishment.  The initiator appends 5 tuple of the 
> packet flow to
> >    be handled by the newly forked context.  Note that the additional
> >    information provided by the 5 tuple are source and 
> destination port
> >    numbers and upper layer protocol.  The information is 
> later used by
> >    the shim sub-layer to multiplex the outbound packet flow on the
> >    responder side.
> 
> Hold on, this is hypothetical protocol design in a 
> non-normative appendix of an API spec. That seems completely 
> out of place. If this issue is important, maybe the whole 
> appendix should be a separate draft?

I see.  I agree that it should be outside the API spec.
The importance of the issue depends on frequency of the scenario
(i.e., multiple applications share the same SHIM6 context), I think.

Regards,
Shinta