Re: [MULTIMOBSEC-API] api requirements

[Shinta Sugimoto <[e-mail]>]

Hi,

Attached please find the latest version of the API draft.
Updates were made based on the comments from Marcelo and Miika.

Regards,
Shinta

On Tue, 23 May 2006 11:22:30 +0300
Shinta Sugimoto <[e-mail]> wrote:

> Hi Marcelo,
> 
> Thank you for your comments.  I reflected most of your editorial
> comments except some items that I need clarification.  Please find
> my comments inline.
> 
> [snip]
> 
> > 1.  Introduction
> > 
> >    This document specifies socket API for multihomed shim layer.
> > 
> > MB: i would rephrase as
> >    This document specifies a/the socket API for a multihoming shim layer.
> 
> done (with 'a').
> 
> > 
> >    The
> >    API aims to enable interactions between application and the multihome
> > 
> > MB: s/mulithome/multihoming
> 
> done.
> 
> >    shim layer for advanced locator management and interface to access
> >    essential information about failure detection and path exploration.
> > 
> > MB: i would remove essential
> 
> 'essential' removed.
> 
> [snip]
> 
> > 3.  Terminology
> > 
> >    This document does not intend to give new definitions for technical
> >    terms that are relevant to multihomed environment but tries to
> >    inherit definitions provided in the existing documents as listed
> >    below:
> > 
> >    o  SHIM6 Protocol Specification[I-D.ietf-shim6-proto]
> > 
> >    o  HIP Architecture[I-D.ietf-hip-arch]
> > 
> >    o  Reachability Protocol (REAP)[I-D.ietf-shim6-failure-detection]
> > 
> >    For clarification, we provide definition for the terms that are
> >    frequently used in this document:
> > 
> >    o  Endpoint Identifier (EID) - An identifier used by the application
> >       to specify an endpoint of the communication.  As addressed in
> >       [I-D.ietf-shim6-app-refer], application may handle EID in various
> >       ways in different types of communication models such as long-lived
> >       connection, callback, and referral.
> > 
> >       *  In case of SHIM6, the EID is called ULID.  ULID is chosen from
> >          one of available locators on the host.
> > 
> >       *  In case of HIP, the EID is essentially a public key of the
> >          host.  In order to preserve backward compatibility of legacy
> >          application, hash of public key called Host Identity Tag (HIT)
> >          is used by application as a handler of EID.
> > 
> > MB s/handler of/handle for the
> 
> done.
> 
> > 
> > 
> >    o  Locator - IP address actually used to deliver the IP packet.
> > 
> > MB: s/IP address/An IP address
> 
> done.
> 
> > 
> >       Locator should be present in the source and destination field of
> >       IP header of a packet that appears on wire.  Normally, locator is
> > 
> > MB: s/locator/a locator
> 
> done.
> 
> > 
> >       assigned to the network interface of the host.  And the IP packet
> >       destined to given locator is delivered to the network interface by
> > 
> > MB: s/to given locator/to a given locator
> 
> done.
> 
> > s/the network interface/to the correspondent network interface
> 
> done.
> 
> > 
> >       the routing system.
> > 
> >    o  Shim - A conceptual layer inside the IP Layer which maintains
> >       mappings of EID and locator.  An EID can be associated with more
> > 
> > MB: s/ mappings of EID and locator/ mappings between EIDs and locators
> 
> done.
> 
> > 
> >       than one locators at a time when the host is multihomed.  From
> >       network architecture perspective, shim should be even or lower
> >       than the IPsec layer.  It should be noted that the term 'shim'
> >       does not refer to specific protocol but refers to a generic
> >       concept of a layer that enables separation of identifier and
> >       locator.  SHIM6 and HIP are examples of the shim.
> > 
> >    o  Context - A state information to be shared by the peers, which
> >       essentially stores a binding of EID and associated locators.  The
> > 
> > MB: s/binding of/ binding between the
> 
> done.
> 
> > 
> > TBD                      Expires August 5, 2006                 [Page 5]
> > 
> > Internet-Draft             Multihomed Shim API             February 2006
> > 
> > 
> >       context is maintained inside the host at the shim layer.
> > 
> > s/inside the host at the shim layer/ at the shim layer of the host
> 
> done.
> 
> > 
> >    o  List of Locators - A list of available locators on the host.
> > 
> > MB: this sounds like the list of locators is only for the local host,
> >  while the list of locators can also be for the remote host.
> > I would say, the list of locators associated with a EID or something like this...
> > 
> >        The
> >       list should be stored in a context, which tells all available
> >       locators for the communication based on EID pair.
> > 
> > MB: the list of locators is asociated to a EID not to a EID pair or a context... 
> > i mean there are TWO list of locators in a single context, one per EID of the context...
> 
> Correct.  rephrased as follows:
> 
> <t>List of Locators - A list of locators associated with an EID.
> There are two lists of locators stored in a given context, one
> is associated with local EID and the other is associated with
> remote EID.  As defined in <>, list of locators associated with
> an EID 'A' can be denoted as Ls(A).
> 
> >       As defined in
> >       [I-D.ietf-shim6-proto], list of locators of a host whose EID is
> >       'A' can be denoted as Ls(A).
> > 
> >    o  Preferred Locator - The (source/destination) locator currently
> >       used to send packets.  As defined in [I-D.ietf-shim6-proto],
> >       preferred locator of a host whose EID is 'A' can be denoted as
> >       Lp(A).
> > 
> >    o  Reachability Detection - A procedure to detect reachability
> >       between given locator pair.
> > 
> > MB: s/between given/between a given
> 
> done.
> 
> > 
> > 
> >    o  Path - A sequence of routers that an IP packet goes through to
> >       reach the destination.
> > 
> >    o  Path Exploration - A procedure to explore available path for given
> >       locator pairs.
> > 
> > MB: s/for given locator pairs/for a given set of locator pairs
> 
> done.
> 
> > 
> > 
> >    o  Outage - An incident meaning that the reachability among given
> > 
> > MB: s/among given/among a given
> 
> done.
> 
> 
> >       locator pair is lost.  The outage could be caused by any kinds of
> >       problems inside the routing infrastructure and problems of network
> > 
> > MB: s/of network/of the network
> 
> done.
> 
> > 
> >       interface of the end hosts.
> > 
> >    o  Working Address Pair - An address pair is said to be working if
> >       the packet containing the first address from the pair as source
> >       address and the second address from the pair as destination
> >       address can safely travel from the source to the destination, and
> >       vice versa.
> > 
> > MB: remove and vice versa since the definition is an ordered address pair...
> 
> done.
> 
> > 
> >   If the reachability is confirmed in both directions,
> >       the address pairs is said to be bi-directional.  Otherwise, it's
> >       unidirectional.
> > 
> >    o  REAP - A protocol for detecting failure and exploring reachability
> >       in multihomed environment.  REAP is defined in[I-D.ietf-shim6-
> >       failure-detection].
> > 
> >    o  Endpoint Descriptor (ED) - The representation of endpoints is
> >       hidden from the applications.
> > 
> > MB: i am not sure what does this sentence means here
> > 
> >       ED is a "handle" or "pointer" to
> >       the actual EID.  A given ED serves as a AID [I-D.nordmark-multi6-
> >       noid].
> > 
> > MB: i haven't read the noid draft recently, but afair and AID was just as a ULID not a ED... (at least no more than a shim ULID)
> 
> I would leave definitions of ED to Miika.  Miika ?
> 
> from <draft-nordmark-multi6-noid-02.txt> Section 1.2:
> 
> >       Application identifier (AID)
> >                   - an IP locator which has been selected for
> >                     communication with a peer to be used by the upper
> >                     layer protocol.  128 bits.  This is used for
> >                     pseudo-header checksum computation and connection
> >                     identification in the ULP.  Different sets of
> >                     communication to a host (e.g., different
> >                     connections) might use different AIDs in order to
> >                     enable load spreading.
> 
> So, it sounds like notion of AID is similar to that of ULID in SHIM6
> as Marcelo pointed out.
> 
> [snip]
> 
> > 5.  Requirements
> > 
> >    Following is a list of requirements from the application perspective.
> >    These requirements are mainly identified during the discussions on
> >    SHIM6 WG mailing list.  Some requirements are derived from
> >    Reachability Protocol document[I-D.ietf-shim6-failure-detection].
> > 
> >    o  Locator management.  Locator management is role of shim layer to
> > 
> > MB: s/of shim/of the shim
> 
> done.
> 
> >       select a pair of locators for sending IP packets within given
> > 
> > MB: s/within given/within a given
> 
> done.
> 
> >       context.  The selection is made by taking miscellaneous conditions
> >       into account such as reachability of path, application's
> > 
> > MB: s/of path/of the path
> 
> done.
> 
> >       preference, and characteristics of path.  From application's
> > 
> > MB: s/of path/of the path
> 
> done.
> 
> > 
> >       perspective:
> > 
> >       *  It should be possible to obtain list of locators of the host
> >          within a given context.  Ls(local) and Ls(remote).
> > 
> >       *  It should be possible to obtain preferred locator of the node
> >          within a given context.  Lp(local) and Lp(remote).
> > 
> >    o  Notification from application to shim layer about the status of
> > 
> > MB: s/from application to shim/from the application to the shim
> 
> done.
> 
> > 
> >       communication.  Note that the notification is made in event based
> > 
> > MB: s/of communication/of the communication
> > s/in event/in an event
> 
> done.
> 
> > 
> >       manner.  There are mainly two aspects of the feedback that
> >       application or upper layer protocol may provide for shim layer,
> >       positive and negative feedbacks [NOTE: These feedbacks are
> >       addressed in sectoin 4.3 and section 5.2 of REAP specification]:
> > 
> >       *  Positive feedback could be given by application or upper layer
> > 
> > MB: s/by application/by the application
> 
> done.
> 
> > 
> >          protocol (e.g.  TCP) to the shim layer informing that its
> >          communication is going well.
> > 
> >       *  Negative feedback could be given by application or upper layer
> > 
> > MB: s/by application/by the application
> 
> done.
> 
> >          protocol (e.g.  TCP) to the shim layer informing that its
> >          communication status is not satisfactory.  TCP could detect a
> >          problem when it does not receives expected ACK from the peer.
> >          ICMP error messages delivered to the upper layer protocol could
> >          be a clue for application to detect any kind of problem.  REAP
> >          module may be triggered by these negative feedbacks and invoke
> >          procedure of path exploration.
> > 
> >    o  Feedback from application to shim layer.  The application should
> >       be able to inform the shim layer about the timeout values for
> >       detecting failure, for sending keepalives, for starting the
> >       exploration procedure.  In particular, the application should be
> >       able to suppress the keepalives.
> > 
> >    o  Hot-standby.  Application may request shim layer if hot-standby
> >       connection is needed.  In this case, alternative paths are known
> > 
> > 
> > 
> > TBD                      Expires August 5, 2006                 [Page 8]
> > 
> > Internet-Draft             Multihomed Shim API             February 2006
> > 
> > 
> >       to be working.  Hence it is possible for the host to immediately
> >       replace the current locator pair with the alternative locator
> >       pair.  Hot-standby may allow application to achieve better
> >       failover.
> > 
> >    o  Eagerness of locator exploration.  Application should be able to
> >       specify shim layer how aggressive it wants to search alternative
> > 
> > MB: i think this sentence needs rewording...
> 
> Does this sound better ?
> 
> <t>Eagerness of locator exploration.  The application should be able
> to inform the shim layer how proactive it wants REAP mechanism to perform
> path exploration (e.g. specifying the number of concurrent attempts of
> discovering working locator pair) when an outage occurs on the path between
> the currently selected locator pair.</t>
> > 
> >       path (e.g. specifying the number of concurrent attempts of
> >       discovering working locator pair) when an outage occurs on the
> >       path between the currently selected locator pair.
> > 
> 
> [snip]
> 
> > 6.  Issues of Handling Multiple Locators with shim unaware applications
> > 
> >    In multihomed environment where either or both of the peers have
> >    multiple locators, there are some issues with legacy socket API.
> > 
> > 6.1.  Initial Contact
> > 
> >    When application is going to establish communication with its peer
> >    who happens to have multiple locators, there are some issues to
> >    consider.  In connection oriented communication, connect() system
> >    call is used to make the initial contact to the peer, which requires
> >    IP address and port number to specify the endpoint.  Hence, name-to-
> >    address resolution should be performed prior to connect().
> >    Application needs to resolve FQDN of the peer to an IP address by any
> >    available name-to-address conversion method.
> > 
> >    In typical case, the application receives information from resolver.
> >    If the application ends up with receiving multiple IP addresses to
> >    reach the peer, it should iterate each destination address one-by-
> >    one.  It should be noted that the host may also have multiple source
> >    addresses.
> > 
> >    The different resulting address pair may have different reachability
> >    status so, in order to find a working address pair, it may be
> >    required to explore all the available address pairs (as opposed to
> >    explore all available destination addresses).
> > 
> >    In normal case, application issues connect() by specifying resolved
> >    IP address of the peer.  If the connect() fails, IP address is
> >    iterated one by one sequentially until working pair is found.
> >    Another approach is to initiate concurrent connect() with every
> >    locator of the peer. connect() can also be called in a sequence which
> >    would probably require more time to find the working pair.
> > 
> >    There could be another case where involvement of shim layer is
> >    expected for handling initial contact.
> > 
> > MB: which is the previous case where the shim was involved in?
> > i mean the next is "another case" is there a previous case?
> > maybe s/there/this ?
> 
> yes, the sentence is misleading.  I rephrased as "Besides, there
> is a case where involvement of the shim layer is expected... "
> 
> > 
> > 
> >    In such case, behavior of
> >    shim layer will depend on presence of required context.  If there
> >    exists the context for the EID specified in the connect(), the
> >    initial contact can be made in accordance with the context
> >    information.  Otherwise, shim layer should invoke context
> >    establishment with the peer EID specified in the argument for
> >    connect().
> > 
> >    Additional efforts would be required in a case where the peer cannot
> >    be reachable by the EID (for example, EID is non-routable or non-IP
> >    reachable) but can be reached by alternative locator.  In particular,
> >    shim layer should somehow discover the alternate locator for the EID
> >    to establish context.  [I-D.nordmark-shim6-esd] addresses the
> > 
> > 
> > 
> > TBD                      Expires August 5, 2006                [Page 10]
> > 
> > Internet-Draft             Multihomed Shim API             February 2006
> > 
> > 
> >    possible approach to perform reverse DNS lookup from EID to FQDN,
> >    then perform forward lookup again to find the full-set of locators
> >    and EID.
> > 
> >    In HIP, resolving HITs to IP addresses using DNS is not feasible
> >    because HITs do not contain any hierarchical information.  To
> >    mitigate this problem, there are a few alternatives.  Firstly,
> >    resolver library on end-host can be modified to provide HIT-to-IP
> >    mappings for HIP software module.  Secondly, a distributed hash table
> >    (DHT) service can be used for storing and looking up the mappings
> >    because it supports non-hierarchical identifiers, such as HITs
> >    [I-D.ietf-hip-arch].  Thirdly, it is possible to use IP addresses in
> >    legacy applications as described in [I-D.henderson-hip-applications].
> > 
> 
> [snip]
> 
> > 8.  Further Issues
> > 
> >    Followings are issues that need further considerations.
> > 
> > 8.1.  Additional Requirements from Applications
> > 
> >    Followings are additional requirements.  At the moment, it is not
> >    certain if these features are commonly needed in all the targeted
> >    multihomed environments (SHIM6 and HIP).  These requirements are
> >    mainly identified during discussions made on SHIM6 WG mailing list.
> > 
> >    o  The application should be able to select a locator pair.
> > 
> >    o  The application should be able to set preferences for the
> >       locators, local and remote one and also to the preferences of the
> >       local locators that will be passed to the peer.
> > 
> > MB: i think here it should be included the description of the discussion
> > about whether an app can select soemthing for a context that will affect
> > all the other apps that are using this
> 
> Noted.  A context can be by definition, shared by apps, so if we let
> app to specify 
> 
> > Actually i think this is a relevant discussion in general (for instance for
> > negative and positive feedback, timers and so on) because the settings/information
> > passed by a single application would affect all other apps using the context.
> > I think that we need a section disucssing how to manage the case where there
> > are multiple apps that are source of information to the shim and how we can
> > deal with contradictory information in particular 
> > 
> 
> I agree.  Race condition should be avoided.
> I think this issue is common to BTNS in case of connection latching.
> Specific SA parameters should be chosen for a given application.
> 
> And we may also learn from past experience (existing systems).
> In some of major Operating Systems, it is possible for application to
> configure per-socket IPsec policy by setsockopt().  By doing so, policy
> enforcement could be done in per-socket manner.  Well, per-socket does
> not necessariliy mean per-application, but...  In those cases (systems
> that allows app to specify per-socket IPsec policy), IPsec policy
> could be either system-wide or per-socket.  Per-socket policy must not
> be applied to flow of application that has no association with the
> policy entry.  Question is which policy to apply for when both system-wide
> policy and per-socket policy match.  Probably per-socket policy
> should override the system-wide policy in any case of race condition.
> 
> I will add new section for this issue.  Thank you for pointing this out.
> 
> > 
> >    o  Don't apply shim.  Application should be able to request shim
> >       layer not to apply Identifier/Locator adaptation but to apply
> >       normal IP processing at the IP layer.
> > 
> > MB: this is already mentioned in the above requirements and i think this is required (i.e. it is not for discussion)
> 
> Yes.
> 
> > 
> > 
> >    o  Application should be able to specify if it wants to defer the
> >       context setup or it wants context establishment to be started
> >       immediately if there is no available context.  In such way,
> >       application can 'upgrade' the connection providing in a sense that
> >       identifier and locator are managed separately.
> > 
> > 
> > MB: I think this should be supported
> 
> Ok.
> 
> [snip]
> 
> 
> Regards,
> Shinta
> 
> _______________________________________________
> MULTIMOBSEC-API mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/multimobsec-api

_______________________________________________
MULTIMOBSEC-API mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/multimobsec-api