Subject: [MULTIMOBSEC-API] RE: update of api draft

From: "Shinta Sugimoto \(TO/NRJ\)" <[email-masked]>
Date: Tue, 6 Jun 2006 13:59:24 +0900

Hi Kristian,
(ccing multimobsec-api list)

Thanks for your comments! Please find my answers below.
You might find difficult to find my replies inline, but they are
marked with "Shinta:", so I hope you can find them.

2.  Target

   Expected readers of this document are: application programmer who
   develops application software which may run on top of multihomed
   environment.  In particular, the API should be beneficial for
   application development of the software which takes advantage of
   multihomed environment aiming to achieve better failover.

Kristian: Is this correct? I don't think this is only for multihomed
environments.
          My assumption is that we want to describe general API for all
shim-like 
          layers.

Shinta: I think the draft is focusing on multihoming features. The aim
is
to allow app to access the shim layer to get information about locator
management and REAP (failure detection & path exploration).

[snip]

             Table 1: Socket Options for Multihomed Shim Layer

   +----------------------+-----+-----+----------------+------+--------+
   | optname              | get | set | description    | flag | dtype  |
   +----------------------+-----+-----+----------------+------+--------+
   | SHIM_APPLY           | o   | o   | When the       | o    | int    |
   |                      |     |     | option is set  |      |        |
   |                      |     |     | by             |      |        |
   |                      |     |     | setsockopt(),  |      |        |
   |                      |     |     | the            |      |        |
   |                      |     |     | application    |      |        |
   |                      |     |     | explicitly     |      |        |
   |                      |     |     | requests the   |      |        |
   |                      |     |     | shim layer for |      |        |
   |                      |     |     | serving        |      |        |
   |                      |     |     | multihome      |      |        |
   |                      |     |     | support. When  |      |        |
   |                      |     |     | set by         |      |        |
   |                      |     |     | getsockopt(),  |      |        |
   |                      |     |     | receives if    |      |        |
   |                      |     |     | the socket is  |      |        |
   |                      |     |     | associated     |      |        |
   |                      |     |     | with any shim  |      |        |
   |                      |     |     | context or     |      |        |
   |                      |     |     | not.           |      |        |
   |                      |     |     |                |      |        |

TBD                      Expires August 5, 2006                [Page 10]

Internet-Draft             Multihomed Shim API             February 2006

   | SHIM_DONTSHIM        |     | o   | Request not to | o    | int    |
   |                      |     |     | apply any shim |      |        |
   |                      |     |     | support for    |      |        |
   |                      |     |     | this           |      |        |
   |                      |     |     | communication. |      |        |

Kristian: Are we mixing two different things with these two options?
In the former one you A) reguest shim mode and B) check if shim is used.
In the latter one you C) request shim mode not to be used.

Shinta: I think you are right. But talking with Marcelo, I realized that
B) needs more accurate definition. Please see below.

I think the A and C case are logically the same (on/off), and whether
shim is
used or not is separate issue.
So I'd suggest:
SHIM_APPLIED (read-only) - Check if socket is associated with any shim
context

SHIM_DONTSHIM (read/write) - if 0, shim is applied (default), if set to
1,
                             shim is disabled.

Shinta: I think your suggestion is better than what is stated in the
current draft.  But let me clarify a bit about SHIM_APPLIED
(or whatever called).  It's basically for allowing app to know whether
if it has any associated shim context with its socket.  Such feature
is useful when the locator information is not useful to determine if
there is any associated context with the socket.  Note that EID
pair and locator pair could be the same, in some case (particularly
in case of SHIM6).  So, to be more specific, it's not about whether
if shim is applied or not, but it's about if the socket is associated
with any shim context or not.  So, I would propose
SHIM_ASSOCIATED (read-only). Does this sound fine ?

   |                      |     |     |                |      |        |
   | SHIM_STANDBY         |     | o   | When set, the  | o    | int    |
   |                      |     |     | application    |      |        |
   |                      |     |     | requests the   |      |        |
   |                      |     |     | shim layer to  |      |        |
   |                      |     |     | prepare        |      |        |
   |                      |     |     | hot-standby    |      |        |
   |                      |     |     | connection     |      |        |
   |                      |     |     | besides the    |      |        |
   |                      |     |     | current        |      |        |
   |                      |     |     | locator pair.  |      |        |
   |                      |     |     |                |      |        |
   | SHIM_PATHEXPLORE     |     | o   | When set, the  | o    | int    |
   |                      |     |     | application    |      |        |
   |                      |     |     | specifies how  |      |        |
   |                      |     |     | many path      |      |        |
   |                      |     |     | explorations   |      |        |
   |                      |     |     | are required   |      |        |
   |                      |     |     | for this       |      |        |
   |                      |     |     | communication. |      |        |
   |                      |     |     |                |      |        |
   | SHIM_LOCPAIR_PREF    | o   | o   | get or set     |      | lcinfo |
   |                      |     |     | preferred      |      |        |
   |                      |     |     | locator pair   |      |        |
   |                      |     |     | of the shim    |      |        |
   |                      |     |     | context        |      |        |
   |                      |     |     | associated     |      |        |
   |                      |     |     | with the       |      |        |
   |                      |     |     | socket.        |      |        |
   |                      |     |     |                |      |        |
   | SHIM_LOCPAIR_RECV    | o   |     | get the        |      | lcinfo |
   |                      |     |     | locator pair   |      |        |
   |                      |     |     | of the last IP |      |        |
   |                      |     |     | packet which   |      |        |
   |                      |     |     | was received   |      |        |
   |                      |     |     | through the    |      |        |
   |                      |     |     | socket.        |      |        |

Kristian: I think we decided to use the control message block in the
recvmsg()
          (struct msghdr -> msg_control). My guess is that this would be
more
          usable than explicit getsockopt() call.
          If application has asked OS to provide information about
received
          packets, then I see no harm in returning that information with
the
          actual data.

Shinta: I agree that getting locator pair informatino from the ancillary
data
attached to the return value from the recvmsg() would be more useful.
But I think getsockopt() should also be possible to obtain the lastly
received
locator pair.  It could be used anytime while recvmsg() is only called
when
there is a data.

          However, I see one possible gray area: connected TCP-socket.
Usually
          when you do read() on such a socket, due to the stream nature
of TCP,
          you can receive data from more than one actual IP-packet. How
do you
          know to which one the control headers/locator pair is
associated?

Shinta: Yes, you are right.

          I understand that this is per-socket, but packets in
multi-homed
          environments may traverse different paths on per-packet basis.

Shinta: Correct.

          Ok, I noticed that you are discussing this below...

Shinta: Yes, I hope that the text provided in Section 6.1 is enough.

   |                      |     |     |                |      |        |
   | SHIM_LOCLIST_LOCAL   | o   |     | get locator    | TBD  | *1     |
   |                      |     |     | list           |      |        |
   |                      |     |     | associated     |      |        |
   |                      |     |     | with local     |      |        |
   |                      |     |     | EID.           |      |        |

TBD                      Expires August 5, 2006                [Page 11]

Internet-Draft             Multihomed Shim API             February 2006

   | SHIM_LOCLIST_REMOTE  | o   |     | get locator    | TBD  | *1     |
   |                      |     |     | list           |      |        |
   |                      |     |     | associated     |      |        |
   |                      |     |     | with remote    |      |        |
   |                      |     |     | EID.           |      |        |
   |                      |     |     |                |      |        |
   | SHIM_TIMER_KEEPALIVE |     | o   | inform shim    | o    | int    |
   |                      |     |     | layer about    |      |        |
   |                      |     |     | the timer      |      |        |
   |                      |     |     | value of       |      |        |
   |                      |     |     | keepalive      |      |        |

Kristian: Not necessarily HIP related, but could well be in future.

Shinta: OK.

   |                      |     |     |                |      |        |
   | SHIM_NOTIFY          |     | o   | provides the   | o    | *2     |
   |                      |     |     | shim layer     |      |        |
   |                      |     |     | positive or    |      |        |
   |                      |     |     | negative       |      |        |
   |                      |     |     | feedbacks.     |      |        |
   +----------------------+-----+-----+----------------+------+--------+

[snip]

6.1.  Specifying Shim Specific Ancillary Data

   By specifying shim specific ancillary data for recvmsg() or
   sendmsg(), application can obtain or specify locator information of
   the datagram to be received/transmitted through a given socket.

   Table 2 provides shim specific ancillary data which can be used for
   recvmsg() or sendmsg().  In any case, SOL_SHIM must be specified as
   the cmsg_level.  Shim specific socket option should be specified in
   cmsg_type.  A pointer to the buffer for storing ancillary data should
   be set as cmsg_data[].

TBD                      Expires August 5, 2006                [Page 13]

Internet-Draft             Multihomed Shim API             February 2006

                   Table 2: Shim specific ancillary data

     +----------------------+-------------------+--------------------+
     | opt_level/cmsg_level | optname/cmsg_type | optval/cmsg_data[] |
     +----------------------+-------------------+--------------------+
     | SOL_SHIM             | SHIM_LOCPAIR_RECV | lcinfo structure   |
     |                      |                   |                    |
     | SOL_SHIM             | SHIM_LOCPAIR_SEND | lcinfo structure   |
     +----------------------+-------------------+--------------------+

   It should be noted that above cmsg_type are basically for UDP and raw
   sockets, not for TCP sockets.  As explained in [RFC3542], there is no
   one-to-one mapping of send/receive operations and the TCP segments
   being transmitted/received.  In case of TCP, application may use
   setsockopt() or getsockopt() to access to or specify some of locator
   information provided by the shim layer.

6.1.1.  SO_LOCPAIR_RECV

   Application can obtain locator information, namely the locator pair
   used to carry the IP packet, by recvmsg() referring to the ancillary
   data that comes with SO_LOCPAIR_RECV cmsg_type.

   The cmsg_data[] should contain locinfo structure which contains the
   locator pair.

6.1.2.  SO_LOCPAIR_SEND

   Application can specify locator pair to be used for transmitting an
   IP packet by sendmsg().  Ancillary data containing SO_LOCPAIR_SEND
   cmsg_type with the locator information shall be passed to sendmsg().

   Note that the effect is limited to the IP packet transmitted by the
   call.  If the locator pair seem to be working and already verified,
   it overrides the decision of the shim layer.

   ISSUE: We should consider error handling in this case, particularly,
   in a case where invalid peer locator was specified by the
   application.  In case of SHIM6, there are two kinds of verifications
   required in order to specify send IP packets to the peer's new
   address; one is return routability (check if the peer is actually
   willing to receive data with the specified locator) and the other is
   verifications based on given crypto locator mechanisms[RFC3972],
   [I-D.ietf-shim6-hba].  What kind of error message should be provided
   for the caller ?  Is EINVAL is enough or do we need to introduce new
   error message (e.g.  EINVALIDLOCATOR) ?

Kristian: I'm for the EINVALIDLOCATOR (or just EINVAL(ID)LOC), just
because
          EINVAL is very overloaded. Almost every function returns
EINVAL,
          and as such it doesn't really tell what the problem is.

Shinta: I agree.

[snip]

7.  Data Structures

   In this section, data structures newly defined for the API are
   presented.  Structure locpair holds a pair of locators for local and
   remote hosts.  Note that the address family of the locator pair could
   be either IPv4 or IPv6.  However, address family of each locator
   within a pair must be identical.

       struct locinfo {
               TBD
       };

       struct locpair {
               struct sockaddr lcp_local;
               struct sockaddr lcp_remote;
       };

Kristian: This is no good, since you are reserving space only for struct
sockaddr
          but for IPv6 that is not enough. Probably struct
sockaddr_storage, or
          just a pointers to struct sockaddr * would be file too.
          I think the first one would be more usable, although consuming
500 bytes
          of extra memory.

Shinta: You are right. sockaddr_storage should be used, I think.

[snip]

8.  Implications for Existing Socket API Extensions

   As the socket options proposed in this document allow application to
   specify locator for transmitting IP packet, there may be conflict
   with advanced socket API for IPv6[RFC3542].

   [RFC3542] defines that IPV6_PKTINFO can be used by application to
   influence outgoing datagram (source address, outgoing interface etc.)
   and obtain information of incoming datagram (destination address,
   receiving interface etc.).  Then a question may rise, what is the
   expected consequence of the case where IPV6_PKTINFO and
   SHIM_LOCPAIR_SEND is specified at the same time.  Similar question
   may rise, what if the IPV6_PKTINFO and SHIM_LOCPAIR_RECV are set at
   the same time.

   ISSUE: We should clarify implications for existing socket API
   features, especially IPV6_PKTINFO as it has some implications on
   locator selection.  In some case, there might be contradictory case
   where IPV6_PKTINFO and SHIM_lOCPAIR_SEND/SHIM_LOCPAIR_RECV are
   specified at the same time.

Kristian: My initial reaction would be to prioritize shim, if 
          SHIM_DONTSHIM socket option is NOT set. Otherwise follow 
          IPV6_PKTINFO options.

Shinta: I see. IMHO, we should sort out PKTINFO 

for outbound, PKTINFO allows app to specify following:

1) source IPv6 addres
2) output interface (ifindex)
3) hop-limit
4) next-hop address

The conflict with the shim layer may affect 1) and 2).
For 1), it should be handled above the shim layer. However,
I don't think 2) can be done in that way.  I mean, if the shim
layer is present and performing locator switch based on a
context information, there is no gurantee that 2) can be
done as the app specified.  So, I think we should mention
in the draft that 2) may be affected by the API.

for inbound, PKTINFO allows app to receive following:

1) destination IPv6 address
2) receiving interface (ifindex)
3) hop-limit

IMHO, 1) should return destination EID, but I am not sure
about 2).  Should 2) return actual interface from which the
IP packet was received or return the interface to which
destination EID is assigned ?  Any comments ?

Regards,
Shinta

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 7 Jun 2006 13:17:36 +0300

>           My assumption is that we want to describe general API for all

well, we are describing a API for all shim like layers, but only the 
part that handles the multiple locators. (and heavily biassed for the 
case where the multiple locators are due to multihoming as oposed to 
the mobility case)

I think we could contrast it with what it would be needed in the 
mobility case i.e. in the case the host has multiple locators because 
of mobility and see if it make sense to integrate it in this draft

OTOH, i don't think it would be possible that the API covers other more 
specific parts of the shim management in the general case i.e. 
establishing a shim6 context and establishing a hip state seems to 
involve somehow different parameters that seem to be specific of the 
particular protocol i guess.

Regards, marcelo

---

From: Kristian Slavov <[email-masked]>
Date: Thu, 08 Jun 2006 12:35:51 +0300

Shinta Sugimoto (TO/NRJ) wrote:
> 1, shim is disabled.

Yes, it does. I guess that is what I had in mind.

> in the draft that 2) may be affected by the API.

Ok, but I'd like to point out that in (many?) cases you want to define 
hop-limit/next-hop based on the knowledge of the output interface AND/OR 
source address. So they might not be meaningful if shim layer changes 1) 
and/or 2).

> 2) receiving interface (ifindex)

Perhaps we need to extend this. Let's consider a scenario with a simple 
connected connection. You are bound to certain EID in both ends (whether 
implicitly or explicitly, doesn't matter). You can query this EID by other 
means (getsockopts, right?). However, if you want to see which destination 
locator the peer used, that you cannot know. So in this scenario returning 
  1, 2 and 3 as is, is fine. (I'm assuming hop-limit equals to the 
remaining hops in the incoming packet)

However, if we have a diagnostics application, or something else that 
listens to all kinds of traffic, then we probably could also use options:
4) EID

This allows the application to find out to which shimmed context the 
packet also belongs.

 > destination EID is assigned ?  Any comments ?

The information about to which destination EID is assigned, is not 
important. You can find that out by other means. For example, having the 
EID and querying interfaces' addresses.

So, in short: 1,2,3 as is. Add 4) EID/ULID

-- 
Kristian Slavov, Research Engineer
Ericsson Research, Nomadiclab
Jorvas, Finland

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 13 Jun 2006 15:14:56 +0300

Hi Kristian,

Sorry for the late reply, but please find my responses inline.

On Thu, 08 Jun 2006 12:35:51 +0300

> Yes, it does. I guess that is what I had in mind.

Ok, now an option SHIM_ASSOCIATED is included in the draft.

> So, in short: 1,2,3 as is. Add 4) EID/ULID

For background info to the list, Kristian and I had off-line
discussion on above issues and reached to preliminary conclusions
on some of them. I think the discussion should be shared by the list,
so let me clarify here:

The issue is mainly about the potential conflict/contradiction that
may be caused by the shim API with legacy API.  The locator management
features in the API allows owner of the socket (app) to

1) get locator information (local/remote) for incoming packet
2) specify locator information (local/remote) for outgoing packet

Some of above features are actually covered by legacy API.
For IPv4 socket, IP_RECVDSTADDR and IP_RECVIF socket options are
defined to get the destination IP address and receiving interface of
the received datagram.  For IPv6 socket, it is also possible to do
that with IPV6_PKTINFO option.

By introducing ID/Locator split in the system model, we should
clarify what the expected behavior of legacy API that deals with
IP addresses or interfaces.

One possible way to figure this out is to assume that all legacy
API should work above the shim layer.  That is, legacy API deals
with identifier aspect of the IP address.  For instance,
IP_RECVDSTADDR will allow app to know the destination EID of
received packet.  If the app wants to deal with locators that lays
below the shim layer, it may use shim API specified in the document.

If we take the assumption above, the draft should probably alert
the usage of legacy API which handles IP address in locator-oriented
way rather than identifier-oriented way.  For instance, obtaining
receiving interface from the ancillary data seems to be useful for
application which is interested in characteristics of physical
interface.  In a system model where shim layer resides inside the
IP layer, those request targeting the layer below the shim layer
should be made by shim API.

Given that, we came to think that SHIM_IF_RECV and SHIM_IF_SEND
maybe useful to override the feature of IP_RECVIF and IPV6_PKTINFO
receiving/specifying the interface.  Note that this does not mean
IP_RECVIF and IPV6_PKTINFO should be deprecated, but they will
remain usable.

In the latest draft, above issues are mainly addressed in Section 9.
Any comments/suggestions are welcome.

Regards,
Shinta