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

From: Miika Komu <[email-masked]>
Date: Mon, 5 Jun 2006 17:31:31 +0300 (EEST)

On Fri, 2 Jun 2006, Shinta Sugimoto (TO/NRJ) wrote:

> Hi all,
>
> Excuse me for the confusion that I send this email to you (in unicast),
> not sending email to the ML <[email-masked]>.
> Now I have limited connectivity to the public Internet and cannot
> send email to the ML (from my personal laptop PC).

No problem. I attached the original version which I am commenting now.

> Anyway, I want to make the status update of the draft.  And would
> like to you receive your quick feedback if you have any.
>
> According to the discussion we had last week, I made some updates
> to the API draft.  Attached please find the draft.  In particular, I
> would
> like to hear your comments on some issues that I realized while I update
> the document (see paragraphs which begin with "ISSUES:").  A couple
> of items were added to the requirements section.  Rest of the changes
> are after section 6.

You might e.g. want to request Petri Jokela (nomadiclab) for an issue 
tracker account in here:

http://hip4inter.net/cgi-bin/roundup.cgi

and keep the issues separate from the actual text. But of course, this is 
a matter of taste.

Here is my feedback for the attached pre-version of the draft:

> 1. Introduction

Based on our discussion at HIIT, should we explicitly mention that SHIM6 
and HIP probably won't work together? This is related to some other 
comments below.

> 5. Requirements
> ...
>   o  Notification from application to the shim layer about the status
>      of the communication.  Note that the notification is made in an
>      event based manner.  There are mainly two aspects of the feedback
>      that application or upper layer protocol may provide for the shim
>      layer, positive and negative feedbacks [NOTE: These feedbacks are
>      addressed in section 4.3 and section 5.2 of REAP specification]:
>
>      *  Positive feedback could be given by the application or upper
>         layer protocol (e.g.  TCP) to the shim layer informing that its
>         communication is going well.
>
>      *  Negative feedback could be given by the application or upper
>         layer 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.

I believe that the last "o" bullet should be a "*" bullet.

>   o  Turn on/off shim.  The application should be able to request to
>      turn on/off the multihome support by the shim layer:
>
>      *  Apply shim.  The application should be able to explicitly
>         request the shim layer to apply multihome support.
>
>      *  Don't apply shim.  The application should be able to request
>         the shim layer not to apply the multihome support but to apply
>         normal IP processing at the IP layer.

s/multihome support/multihiming support/

The "apply shim" bullet does not really mention whether it is "try" or 
"must" apply shim. Remember that the peer may or may not be capable of 
supporting shim. Trying shim means that we can fallback to plain TCP/IP 
communications. Similarly, must means that we want to use shim or nothing 
at all. I believe a separate requirement for both would be nice.

> 6.  Socket Options for Multihomed Shim Layer
> ..
>
> Table 1 provides complete list of the socket options specifically
> defined for interface shim layer.  Note that all socket options are
> defined at level SOL_SHIM.

We have two options here (see my comments on intro):
   a) SOL_SHIM
   b) SOL_HIP and SOL_SHIM6

The first alternative has at least one benefit. If SHIM6 is considered the 
first step towards full locator/id split (i.e. HIP :), then having this 
option would guarantee almost transparent migration path from SHIM6 to 
HIP. The drawbacks are that SHIM6 and HIP cannot be run at the same time 
for the same socket, and that the socket handler implementation might get 
quite fat.

The second alternative reversed benefits and drawbacks when compared to 
the first alternative.

Also, one way to think about this are the protocol specific options. How 
those options should be then defined?

I am leaning towards option b) but having the same SO_SHIM socket options 
for both protocols. However, I am open for ideas.

In addition, should it be IPPROTO_ rather than SOL_? I am little bit 
unsure on this but I think IPROTO_ is the right one, altough SOL _could be 
the alias like it is for e.g. IPPROTO_TCP and SOL_TCP.

Opinions, please?

> The first column of the table gives name of the option.  The second
> and third columns indicates whether if the option is for retrieving
> the date from the kernel or providing data to the kernel (or both).
> The fifth column indicates if the option deals with binary data or
> not.  If the flag is not set, specific data structure (other than
> int) should be used for data exchange.  The data structure is
> provided in the sixth column.

The first column of the table gives name of the option.  The second and 
third columns indicates whether the option applies for retrieving the data 
from the kernel or providing data to the kernel (or both). The fourth 
column summarizes the purpose of the option. The fifth column indicates if 
the option deals with integer type of data or not.  If the flag is not 
set, data structure specific to the socket option (other than int) should 
be used.  The data structure is provided in the sixth column.

> Table 1: Socket Options for Multihomed Shim Layer

* For all option names, please add a SO_ prefix. For example, SHIM_APPLY
   should be SO_SHIM_APPLY
* The flag field is redundant with dtype. Suggest removing flag field and
   explicitly marking it in dtype field.
* The description field is currently too narrow.
* SHIM_STANDBY -> SHIM_HOT_STANDBY
* SHIM_LOCPAIR_PREF and SHIM_LOCPAIR_RECV
   * I suggest removing this pairing concept and using single locators
     instead, unles you have a specific need to do otherwise. E.g.
     have SHIM_LOC_LOCAL_PREF, SHIM_LOC_PEER_PREF and same for RECV.
   * Now, we don't have to introduce another data structure and we can just
     use regular sockaddr structure for these options.

> *2: TBD.

I suggest standard "struct addrinfo" data structure, man getaddrinfo, or:

ftp://ftp.rfc-editor.org/in-notes/rfc3493.txt

After this, I suggest adding a short section on get/setsockopt error 
values. See man get/setsockopt:

RETURN VALUES
      If successful, getsockopt() and setsockopt() return 0;  oth-
      erwise,  the  functions  return -1 and set errno to indicate
      the error.

We could probably mention explicitly that ENOSYS means that the localhost 
does not support shim.

> Figure 2: Socket API system model with shim layer

How about the following figure instead of the current one:

+------------------------------------------+
|              Application                 | socket
+------------------------------------------+

+------------------------------------------+
|               SOL_SOCKET                 | generic socket options
+----------------------------------------- +

+------------+------------+----------------+
| IPROTO_TCP | IPROTO_UDP | IPPROTO_ICMPV6 | transport layer sockets
+------------+------------+----------------+

+---------------------+--------------------+
|     IPPROTO_HIP     |   IPPROTO_SHIM6    | shim layer sockets
+---------------------+--------------------+

+-------------------+----------------------+
|    IPROTO_IP      |    IPPROTO_IPV6      | network layer sockets
+-------------------+----------------------+

> ISSUE: It may be controversial to introduce a new level SOL_SHIM for
> shim specific socket options.  IMHO, we should avoid defining shim
> specific socket options for both in level IPPROTO_IP and IPPROTO_IPV6
> as it's redundant and seems to be architecturally wrong.

I think you can just remove this issue.

> 6.1.  Specifying Shim Specific Ancillary Data
> ..
> Table 2: Shim specific ancillary data

As I noted before we should have separate options for accessing local and 
peer locators, and the lcinfo should be sockaddr.

> It should be noted that above cmsg_type are basically for UDP and raw
> sockets, not for TCP sockets.

s/basically/typically/

It is completely possible to use sendmsg and recvmsg interface for TCP 
also.

> 6.1.1.  SO_LOCPAIR_RECV

See my previous comments locator pairs and locinfo.

> 6.1.2.  SO_LOCPAIR_SEND

See my previous comments locator pairs and locinfo.

> 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) ?

It is an interesting question... for the time being, I think overloading 
ENETUNREACH will do just fine.

> 7.  Data Structures

See my previous comments on these.

> 8.  Implications for Existing Socket API Extensions
> ..
> [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.

I suggest changing the question to a solution proposal. Namemely, PKTINFO 
should specify ULID or transport layer identifier.

> 9.  Issues with a Context Shared by Applications
>
> When a context is shared by applications, it would be difficult for
> the shim layer to handle feedbacks from the applications.  As
> mentioned in Section X, an application may provide the shim layer
> some feedbacks of timeout values from its own settings.  This implies
> that there is potentially a race condition in the shim layer.
> Further discussions are needed how the shim layer can accommodate
> feedbacks from multiple applications within a same context.

I think the only option how to handle race conditions is to use 
prioritizing based on process priviledges (super user vs. regular user) 
and last-process-overwrites-previous-information principle in the case of 
processes with same access priviledges. Also, I think some of the options 
should be accessible only with super user priviledges.

> 10.1.  Initial Contact

In general, I think we should be talking about EIDs, and not addresses, in 
this section, even though it considers legacy applications. The term 
"address" is just too vague.

Also, there is a lot of "loose" text in this section which does not really 
make any good points. I think the text could be crystallized better, but I 
don't have any concrete suggestions at this point of time.

> In connection oriented communication..

In connection oriented communication, connect() system call is used to 
make the initial contact to the peer, which *typically* requires IP 
address and port number to specify the endpoint.

> It should be noted that the host may also have multiple source 
> addresses.

Add: If the application does not specify a source address, the host
will assign automatically a local EID.

> 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).

I believe scanning the source addresses is actually not common in shim 
unaware, legacy applications. Most common scenario 1 x N scanning for 
reachable destination identifiers. This should be noted in the text.

> Besides, there is a case where involvement of the shim layer is
> expected for handling initial contact.

Remove the "besides", it is talkative.

> If there exists the context for the EID specified in the connect(), the 
> initial contact can be made in accordance with the context information.

This case occurs when there exists the context for the EID specified in 
the connect(), the initial contact can be made in accordance with the 
context information.

> 10.2.  Naming at Socket Layer
> 
> As IP address is the key information in the two system calls, there
> is a question if it should be identifier or locator when shim layer
> is present.

Instead of leaving this open here, let's provoke people to discussion by 
proposing it to be the identifier.

> Appendix B.  Specifying Locator Information
> ..
> Note that by using IPv4-mapped address, IPv6 socket may also handle
> IPv4 packet for exceptional cases.  However, this is not the
> recommended due to ambiguity.

Remove the recommendation. This kind of behaviour has been already 
deployed, so there is not much we can do.

P.S. Good work Shinta and Marcelo! I am very pleased with the current pace 
of work. And thanks to Kristian for comments and discussion.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

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

---

From: Kristian Slavov <[email-masked]>
Date: Thu, 08 Jun 2006 10:36:22 +0300

Hi,

Sorry for commenting late.

Miika Komu wrote:
> communications. Similarly, must means that we want to use shim or 
> nothing at all. I believe a separate requirement for both would be nice.

Could this be a policy option rather than API option? Is there a case, 
where the administrator of the system says "ok, falling back is allowed", 
but the application will not want to. I would assume the shim aware 
programs would provide best-effort services, and that includes plain old 
TCP/IP.

The other way around (i.e. policy denies connections that are not 
processed by the shim layer), I can understand very well. All companies 
have security policies and restrictions, and they would like to enforce 
them, regardless of what the programs/users would like to do.

Perhaps I'm just frustrated by software that tells me what I'm allowed to 
do, rather than doing what I want it to do. :)

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

---

From: Miika Komu <[email-masked]>
Date: Thu, 8 Jun 2006 10:56:31 +0300 (EEST)

On Thu, 8 Jun 2006, Kristian Slavov wrote:

> Could this be a policy option rather than API option? Is there a case, where 
> the administrator of the system says "ok, falling back is allowed", but the 
> application will not want to. I would assume the shim aware programs would 
> provide best-effort services, and that includes plain old TCP/IP.
>
> The other way around (i.e. policy denies connections that are not processed 
> by the shim layer), I can understand very well. All companies have security 
> policies and restrictions, and they would like to enforce them, regardless of 
> what the programs/users would like to do.
>
> Perhaps I'm just frustrated by software that tells me what I'm allowed to do, 
> rather than doing what I want it to do. :)

It be a system specific option, but I think applications should be able to 
request it explicitly as well.

IMHO, the draft is more about shim enabled applications rather than 
adminstrative, system level options. I believe that there is little need 
to standardize APIs just for administrative system options because each 
operating system can implement as they want to (even using archaic ioctl 
calls). However, this does not exclude that the API we are defining could 
not be run as super user to get more power :)

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 8 Jun 2006 11:07:52 +0300

El 08/06/2006, a las 10:36, Kristian Slavov escribió:

>> The "apply shim" bullet does not really mention whether it is "try" 
>> or "must" apply shim. Remember that the peer may or may not be 
>> capable of supporting shim. Trying shim means that we can fallback to 
>> plain TCP/IP communications. Similarly, must means that we want to 
>> use shim or nothing at all. I believe a separate requirement for both 
>> would be nice.
>
>
> where the administrator of the system says "ok, falling back is 
> allowed", but the application will not want to. I would assume the 
> shim aware programs would provide best-effort services, and that 
> includes plain old TCP/IP.
>

I think it is important to note a couple of points:
- shim6 default behaviour is deferred setup, meaning that 
communications will start using palin v6 and the later, due to some 
heuristics, they will trigger the shim6 establishmente exchange. At 
this point the peer that attempts to establish the shim6 context may 
well find out tha the peer does not support the shim (or that the shim6 
protocol is blocked or similar). However the interesting thing, is that 
whether the shim6 context is established or not, this does not have 
inmediate concequences for the ongoing communication. the difference 
will be in the case that there is a failure. So, i think that in this 
case, it doesn't makes much sense to interrupt the ongoing 
communication because shim6 is not available. Of course it would make 
sense to notify the application that the shim is not supported, so that 
it knows what to expect (however i would argue that this is shim6 
specific and does not belong to this document)

- shim6 can be used without deferred setup, in a similar fashion than 
the hip defaul behaviour. I guess that in this case it would make sense 
the option of must shim.

Regards, marcelo

> processed by the shim layer), I can understand very well. All 
> companies have security policies and restrictions, and they would like 
> to enforce them, regardless of what the programs/users would like to 
> do.
>
> Perhaps I'm just frustrated by software that tells me what I'm allowed 
> to do, rather than doing what I want it to do. :)
>
> --

---

From: Miika Komu <[email-masked]>
Date: Thu, 8 Jun 2006 12:06:47 +0300 (EEST)

On Thu, 8 Jun 2006, marcelo bagnulo braun wrote:

> - shim6 default behaviour is deferred setup, meaning that communications will 
> start using palin v6 and the later, due to some heuristics, they will trigger 
> the shim6 establishmente exchange. At this point the peer that attempts to 
> establish the shim6 context may well find out tha the peer does not support 
> the shim (or that the shim6 protocol is blocked or similar). However the 
> interesting thing, is that whether the shim6 context is established or not, 
> this does not have inmediate concequences for the ongoing communication. the 
> difference will be in the case that there is a failure. So, i think that in 
> this case, it doesn't makes much sense to interrupt the ongoing communication 
> because shim6 is not available. Of course it would make sense to notify the 
> application that the shim is not supported, so that it knows what to expect 
> (however i would argue that this is shim6 specific and does not belong to 
> this document)
>
> - shim6 can be used without deferred setup, in a similar fashion than the hip 
> defaul behaviour. I guess that in this case it would make sense the option of 
> must shim.

FYI, the similar behaviour may be available for HIP as well later on.