[MULTIMOBSEC-API] RE: update of api draft

[Miika Komu <[e-mail]>]

On Tue, 6 Jun 2006, Shinta Sugimoto (TO/NRJ) wrote:

>> I believe that the last "o" bullet should be a "*" bullet.
>
> This was intentionally separated. The former were dynamic feedback
> while the latter is rather static feedback (timeout values).  Yes, both
> are common in a sense that they are feedbacks from app to the shim
> layer.

(Maybe you could mention on the dynamic vs. static difference in the text)

>> I am leaning towards option b) but having the same SO_SHIM
>> socket options for both protocols. However, I am open for ideas.
>
> I think SOL_SHIM would make sense because we are defining
> "common" socket API for the generic multihoming shim layer.
> The shim layer, by nature, should not be specific to any protocol
> family.  And as we say that its "common" for shim approach
> which is based on ID/Locator separation (e.g. SHIM6, HIP),
> shouldn't we define it in protocol independent way ?

I believe the question boils down to unshared functionality. How to have 
options e.g. for mobility that are not applicable for shim6 but apply for 
HIP. Or public key related things that are shared with btns and hip, but 
do not apply to shim6. On the other hand, if SHIM6 and HIP cannot be used 
simultaneously for a single socket, there should not be a problem?

So, maybe we can use a single shared SHIM contant for the time being and 
split it later if we discover some problems e.g. through implementation 
work.

>> 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?
>
> As the generic concept of the "shim layer" should be protocol 
> independent, it seems reasonable to have prefix "SOL_" rather than 
> "IPPROTO_."  In my understanding, "IPPROTO_" implies specific protocol, 
> but "SOL_" could followed by conceptual layer such as socket or shim 
> layer, IMHO. Does this make sense ?

Regarding to the previous point, maybe IPPROTO_HIP and IPPROTO_SHIM6 could 
be used to separate uncommon features, if necessary. However, seems like 
most of the SOL_XX have a corresponding IPPROTO_XX variable.

So, I am fine with experiment with the SOL_SHIM for the time being.

>>> *2: TBD.
>>
>> I suggest standard "struct addrinfo" data structure, man
>> getaddrinfo, or:
>>
>> ftp://ftp.rfc-editor.org/in-notes/rfc3493.txt
>
> Ok, I think sockaddrs_storage will do the job, as Kristian pointed out.

Wasn't this supposed to be a list?

> Hmm, I personally liked the figure that I borrowed from Steven's book
> (UNIX Networking Programming, vol. 1) and see how the shim layer
> fits into the existing model.  But...

The SOL_SOCKET was not illustarated correctly in the original figure. 
Also, having the packets flying around when talking about socket layering 
was a little bit misleading.

>> +------------------------------------------+
>> |              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
>> +-------------------+----------------------+

(SOL_SOCKET bar could also be reversed 90 degrees since it applies to all 
layers, but the current way may be easier to comprehend)

>>> 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.
>
> Given the discussion above, do you think SOL_SHIM is reasonable ?

Sure let's go for that.

> Agree that root privilege should override normal user settings.
> And partially agree with that some case may be OK to simply updates
> the last value.  But there might be other cases too:
>
> request 1: set timeout value T for 2 hours
> request 2: set timeout value T for 1.5 hours
> request 3: set timeout value T for 3 hours
>
> Suppose if above requests are made sequentially by the entities
> who have same privilege level (say all are root), then what should
> the shim layer do ?  What Marcelo suggested/mentioned in the
> last discussion was to introduce a sort of heuristics to accommodate
> these contradictory requests.  One possible option would be to take
> demanding request; in above example, timeout value is set to 1.5
> hours (request 3 is ignored since it's less demanding).  But I think
> appropriate strategy would dependent on socket options or timeout
> values.

As long as the heuristic are simple, that would be fine.

> Will update the document and reflecting your comments. Thanks again for
> the review!

No problem and apologies for delay in the reply. Remember that Monday is 
cut-off DL, so please remember to submit the draft early :) I hope you or 
Marcelo could present the draft also in the HIP WG in the next IETF.

-- 
Miika Komu              [e-mail]          http://www.iki.fi/miika/

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