Subject: [shim6] AD review of draft-ietf-shim6-multihome-shim-api

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Oct 2010 00:08:46 +0300

I have reviewed this draft. I think the draft is in pretty good shape, I 
have no major concerns. I do have a number of suggested clarifications, 
however. I would like you to update the draft and then we can go to IETF 
last call.

Technical:

> The role of the multihoming shim sub-layer (hereafter called "shim
> sub-layer" in this document) is to avoid impacts to upper layer
> protocols which may be caused when the endhost changes its attachment
> point to the Internet, for instance, in the case of rehoming event
> under the multihomed environment. 

I think this should be stated slightly differently. The point of the 
shim layers is that for most cases, there will be no impacts to upper 
layers. However, the API is necessary for two cases: when the upper 
layer is particularly sensitive to impacts, or when it wants to benefit 
from better knowledge of what is going on underneath.

> Note that the shim sub-layer may conflict with other multihoming
> mechanisms such as SCTP and multipath
> TCP[I-D.ietf-shim6-applicability].  To avoid any conflict, only one
> of SHIM6 and HIP should be in use.
>   

Clarification. Did you intend to say that only one of SHIM6 and HIP 
*and* other multihoming mechanism should be in use?

>       *  In the case of SHIM6, an identifier called a ULID serves as an
>          EID.  A ULID is chosen from locators available on the host.
>   

Define/expand the ULID acronym.

> *  Preferred locator - The (source/destination) locator currently
>    used to send packets within a given context.  As defined in
>    [RFC5533 <http://tools.ietf.org/html/rfc5533>], the preferred locator of a host 'A' is denoted as
>    Lp(A).
>   

Section 6.1 of RFC 5533 talks about Lp(A) as the "current locator", not 
preferred. Text later in Section 4 talks about preferred again. I wonder 
if there's some bigger issue here. Current is not necessarily the same 
as preferred, and I might imagine being able to set either one. I'm 
reading on...

> All of these socket options are defined at
>    level SOL_SHIM.
>   

Please refer to the relevant socket call that defines the level system 
(setsockopt).

> | SHIM_LOC_LOCAL_RECV         | o   | o   | Get or set the  | int   |
> |                             |     |     | parameter which |       |
> |                             |     |     | is used to      |       |
> |                             |     |     | request the     |       |
> |                             |     |     | shim sub-layer  |       |
> |                             |     |     | to store the    |       |
> |                             |     |     | destination     |       |
> |                             |     |     | locator of the  |       |
> |                             |     |     | received IP     |       |
> |                             |     |     | packet.         |       |
> | SHIM_LOC_PEER_RECV          | o   | o   | Get or set the  | int   |
> |                             |     |     | parameter which |       |
> |                             |     |     | is used to      |       |
> |                             |     |     | request the     |       |
> |                             |     |     | shim sub-layer  |       |
> |                             |     |     | to store the    |       |
> |                             |     |     | source locator  |       |
> |                             |     |     | of the received |       |
> |                             |     |     | IP packet.      |       |
>   

I should either get more coffee or the explanations above are not very 
clear.

For instance, I do not understand why it would make sense to set the 
locator of received IP packets. And why do you say "parameter that is 
used to request ... store the ...."?

The opening sentence of Section 5.6 would be better fit here, IMO.

> | SHIM_APP_TIMEOUT            | o   | o   | Get or set the  | int   |
> |                             |     |     | timeout value   |       |
> |                             |     |     | for detecting   |       |
> |                             |     |     | failure.        |       |
>   

Is this a timeout that the application will use to fail whatever it was 
trying to do, or a timeout that the shim should use to start exploring 
proactively, or a timeout that the shim should use to determine that the 
current locators have failed?

The opening sentence of Section 5.12 would be more accurate, IMO.

> The preferred locator can be set by setsockopt().  The shim sub-layer
> shall verify requested locator before it updates the preferred
> locator.
>   
>    An error EINVALIDLOCATOR is returned when the validation of the
>    specified locator fails.
>   

Verify in the security sense (check the HBA) or verify in the 
reachability sense? Will the setsockopt call return before or after 
reachability is verified? What errors are returned if the verification 
fails? Why does the first text fragment talk about verification and the 
second about validation? Are these the same or different thing?

> For example, an application can get the preferred locator by using
> the socket option as follows.
>
>        struct shim_locator lc;
>        int len;
>
>        len = sizeof(lc);
>
>        getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_PREF, &lc, &len);
>   

How do you get/set preferences for multiple addresses? Do you set each 
address separately, or give an array of shim_locators in the socket call?

>  SHIM_LOC_LOCAL_SEND

Can you specify what is the difference to SHIM_LOC_LOCAL_PREF? One sets 
the preference, the other forces a choice?

> For example, an application can get the preferred local locator by
> using the socket option as follows.
>
>        struct shim_locator locator;
>
>        memset(&locator, 0, sizeof(locator));
>
>        getsockopt(fd, SOL_SHIM, SHIM_LOC_LOCAL_SEND, &locator,
>                   sizeof(locator));
>   

Aren't you mixing SHIM_LOC_LOCAL_PREF/SEND in the text and the code above?

>        /* obtain local IP addresses from local interfaces */

The example in Section 5.10 is not that motivating, because presumably 
applications do not need to do anything if they want the shim to use all 
possible addresses from all interfaces.

Secondly, the example uses AF_INET addresses as well, and that is not 
supported by SHIM6. Perhaps that should be pointed out.

> The SHIM_APP_TIMEOUT option is used to get or set the Send Timeout
> value of the REAP protocol.  This option is effective only when there
> is a shim context associated with the socket.
>   
Reference needed.

What does this option do if there is no SHIM6 but, say, HIP underneath?

> EINVALIDLOCATOR
>   This indicates that at least one of the necessary validations
>   inside the shim sub-layer for the specified locator has failed.
>   In case of SHIM6, there are two kinds of verifications required
>   for security reasons prior to sending an IP packet to the peer's
>   new locator; one is the return routability (check if the peer is
>   actually willing to receive data with the specified locator) and
>   the other one is the verification based on crypto identifier
>   mechanisms [RFC3972 <http://tools.ietf.org/html/rfc3972>], [RFC5535 <http://tools.ietf.org/html/rfc5535>].
>   

Please specify what kind of return routability is being employed, do you 
specifically mean REAP and the corresponding checks in HIP?

> 6.2. Set Locator for Outgoing Packet
>
>
>    An application can specify the locators to be used for transmitting
>    an IP packet by sendmsg().  When the ancillary data of cmsg_type
>    SHIM_LOC_LOCAL_SEND and/or SHIM_LOC_PEER_SEND are specified, the
>    application can explicitly specify the source and/or the destination
>    locators to be used for the communication over the socket.  If the
>    specified locator pair is verified, the shim sub-layer overrides the
>    locator(s) of the outgoing IP packet.  Note that the effect is
>    limited to the datagram transmitted by the sendmsg().
>
>    When there is no shim context associated with the socket, an error
>    code ENOENT is returned to the application.
>
>    An error code EINVALIDLOCATOR is returned when validation of the
>    specified locator fails.

If the verification of the locators would require protocol exchanges 
(REAP), will sendmsg block?

> Such feedbacks are particularly useful for the
> shim sub-layer in the absence of REAP mechanism to monitor the
> reachability status of the currently used locator pair in a given
> shim context.
>   

The feedback is useful even with REAP.

>    lc_proto
>       Internet Protocol number for the protocol which is used to handle
>       locator behind NAT.  Typically, this value is set as UDP (17) when
>       the locator is a UDP encapsulation interface.
>    lc_port
>       Port number which is used for handling locator behind NAT.
>   

You lost me here. This is the first time NAT functionality is mentioned. 
Please describe this in more detail, or at the very least, point the 
reader forward to Section 7.1.1.

>    lc_weight
>       The weight value indicates a relative weight for locators with the
>       same priority value.  The range is 0-65535.
>   

Which values are higher priority, 0 or 65535?

>    This document contains no IANA consideration.

Really? Where are the various socket option number spaces allocated?

> 13.1.2. Treatment of Unknown Destination Locator
>
>
>    If the shim sub-layer turns out to be SHIM6, the SHIM6 implementation
>    MUST reject the request for using unknown destination locator.
>
>    If the shim sub-layer turns out to be HIP, the HIP implementation MAY
>    accept the request for using unknown destination locator.

This seems like an insufficiently explained security issue. Why is it OK 
for HIP to do this, or at least you should describe what are 
consequences if it does so?

Editorial:

Please add the standard RFC 2119 reference and boilerplate text (as you 
are using the keywords from there).

>   == You're using the IETF Trust Provisions' Section 6.b License Notice from
>      12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
>      http://trustee.ietf.org/license-info/)
>   

Please switch to the newest boilerplate if and when you update the draft.

>   == Outdated reference: A later version (-22) exists of
>      draft-ietf-behave-v6v4-xlate-21
>
>   == Outdated reference: draft-ietf-hip-nat-traversal has been published as
>      RFC 5770
>
>   == Outdated reference: A later version (-06) exists of
>      draft-ietf-shim6-applicability-05
>   

Update these in the next revision, too.

> In this document, syntax and semantics of the API are given in the
> same way as the Posix standard [POSIX <http://tools.ietf.org/html/draft-ietf-shim6-multihome-shim-api-14#ref-POSIX>]

... in the same way as *in* the Posix standard?

>       provide positive feedbacks or negative feedbacks to the shim sub-

s/feedbacks/feedback/g

> | SHIM_LOC_LOCAL_PREF         | o   | o   | Get or set the  | *1    |

"Note 1" on the last column might be clearer. At least this read was wondering for a few seconds what datatype *1 was :-)

> | SHIM_ASSOCIATED             | o   |     | Get the         | int   |
> |                             |     |     | parameter which |       |
> |                             |     |     | indicates       |       |
> |                             |     |     | whether the     |       |
> |                             |     |     | socket is       |       |
> |                             |     |     | associated with |       |
> |                             |     |     | any shim        |       |
> |                             |     |     | context or not. |       |
>   

Can we say explicitly that 0 = not associated and 1 = associated?

>    *1: cmsg_data[] includes a single sockaddr_in{} or sockaddr_in6{} and
>    padding if necessary
>   

Maybe "... csmg_data[] within msg_control includes ..." (provides the 
reader a better understanding of what you are talking about, since 
caddr_t appears in multiple fields of the struct).

> 7. Data Structures
>
>    This section data structures for the shim sub-layer.

Something is missing here.

>    lc_ifidx
>       Interface index of the network interface to which the locator is
>       assigned.  This field should be valid only in a read
>       (getsockopt()) operation.
>   

... This field is only used in a read ...

>                 uint8_t   pe_probenum;      /* # of initial probe */

... probes

> It is ffs exactly how the shim sub-layer should behave in
>    such erroneous cases.
>   

It is outside the scope of this document to describe how ...

> SHIM_MAX_LOCATORS  The maximum number of the locators to be included
> in a locator list. 32.
>   

Odd formatting.

Jari

---

From: Miika Komu <[email-masked]>
Date: Fri, 08 Oct 2010 08:59:55 +0300

Hi Jari,

> consequences if it does so?

I would suggest to change this text as follows:

If the shim sub-layer turns out to be HIP, the HIP implementation MAY 
accept the request for using unknown destination locator after a 
successful address verification procedure.

Does this work for you?

---

From: Jari Arkko <[email-masked]>
Date: Fri, 08 Oct 2010 11:04:45 +0200

Miika,

> successful address verification procedure.

Not quite. I think the text has to explain what you mean by unknown 
destination locator, and what principle is used to accept new locators, 
and if it is allowed to deviate from those principles what happens.

Specifically, I *think* that you mean in Shim6 you would never accept an 
address outside the HBA set (or verified by CGA). But what about HIP? I 
think you could accept any locator as long as the other side was OK with 
that. However, IIRC in HIP you cannot propose a locator for the other 
side, only for yourself. Or is your plan that you move the session to 
another locator and that if that node happens to be the wrong one, then 
it cannot decrypt the traffic anyway, so there's no damage?

Jari

---

From: Miika Komu <[email-masked]>
Date: Fri, 08 Oct 2010 14:35:18 +0300

Hi,

> and if it is allowed to deviate from those principles what happens.

I believe an unknown destination locator means here a locator that is 
new to the SHIM layer (i.e. not yet included in the SHIM context).

> that.

Good point.

> However, IIRC in HIP you cannot propose a locator for the other

(There has to be a successful return routability check before any 
traffic is transported)

There's two use cases:

1. No HIP session (i.e. SHIM context) yet and application knows the IP 
address of the peer.
2. An existing HIP session, connectivity lost but the application (with 
the assistance from the user) can help to rediscover the peer.

Now remembering this "unknown" part again, I think the MAY was referring 
to the first case described above. It should be ok for the application 
give a hint especially in the absence of better knowledge from the SHIM.

Regarding to the case two, it is true that RFC5206 basically assumes 
that the peer has to announce it's locator set before the local host can 
use them. I believe the peer can refuse to answer if the local host 
triggers a return routability check to an unannounced locator of the 
peer. However, the situation may be changing in RFC5206-bis due to the 
recent advancements in IPv4-IPv6 handovers [1] which are not yet 
included in RFC5206.

Tom, care to comment if I am too proactive here?

[1] Secure and efficient IPv4/IPv6 handovers using host-based 
identifier-locator Split, Samu Varjonen et al, 2009

---

From: Jari Arkko <[email-masked]>
Date: Mon, 11 Oct 2010 00:23:37 +0300

Shinta,

> OK, I see. I agree with your view on the main usecases of the API. Let
> us update the texts in Section 1 (I think we need to modify the first
> and second paragraphs) so that it gives the main usecases of the API.
>   

OK

> No. The paragraph intends to address that
>
> - There are various kinds of technologies that aim to solve the same
> issue (the multihoming issue).
> - There will be conflict when more than one shim sub-layers are active
> at the same time.
> - The assumption made in this document is that there is only a single
> shim sub-layer, which is either of SHIM6 or HIP, is active on the system.
>   

OK. That's what I meant...

> I think we have better rephrase the texts in the paragraph.
>   

OK

> You are right. This is a mistake. I think we can simply remove the
> description about Lp(A) which must denotes a current locator as per
> RFC5533, and keep the descriptions about the notion of preferred locator
> here.
>   

OK

> W.r.t. purpose of the validity check, actually it means both (security
> sense and reachability sense). 

That is good.

> The "validity" of a locator that we are
> discussing in this document is about security. When sending an IP packet
> to the peer's given locator (which is not an HBA) for the first time, a
> return routability check shall be performed as per RFC 5533. This return
> routability check is done for security purpose as I understand it.
>   

I agree that it is needed.

> W.r.t. when the result of validity check is provided to the application,
> setsockopt call shall return after the reachability check, IMO.
>
> W.r.t. the error that should be returned to the application when a
> reachability check fails, EINVALIDLOCATOR shall be return to the app,
> IMO (as the validity check is meant to indicate validity of the address
> in the security sense and reachability sense as mentioned above), IMO.
>
> W.r.t. term of validation and verification, I think we should be more
> strict/precise in the document. Validation should be used in the context
> of security, and verification should be used in the sense of
> non-security (i.e., reachability) context. Let us update the texts in
> the document according to these definitions.
>
> does this make sense?
>   

I think so.

> Application needs to get/set preference for each address, one by one.
>   

Can you state that in the draft as well? It was unclear to me.

> Yes.
> For instance, by allowing application to specify preference for each
> candidate locator, the shim sub-layer can automatically fallback to the
> second best locator according to the preference values given by the
> application.
>
> BTW, this issue (difference of SHIM_LOC_*_SEND and SHIM_LOC_*_PREF) was
> brought up in the past. FYI, you can find the past discussions in the
> following email thread:
> http://www.ietf.org/mail-archive/web/shim6/current/msg02137.html
>
> Maybe there is a room for improvement to make the difference clear.
>   

There is. I don't care what the difference is, but there has to be a 
difference and it has to be clear to the reader.

> No. But I see that the text is confusing/mis-leading. I will rephrase
> the text "For example, an application can get the designated local
> locator by using the socket option as follows." to avoid confusion.
>   

I was referring to the text which is the same in the examples in 
Sections 5.4 and 5.8: "For example, an application can get the preferred 
local locator by using the socket option as follows.". But maybe this is 
again the PREF/SEND confusion. Please clarify.

> I see. But maybe some applications (I have to admit that I have no
> concrete examples here though) may want to get the information and
> decide which one to use, maybe for policy routing.
>   

Right. Well, this comment was not so crucial. If you have an idea about 
another example, use it, otherwise don't worry about it.

> In the absence of REAP, the EOPNOTSUPP error code should be returned to
> the app. Let me add this.
>   

OK

> Yes. Let me update the texts accordingly.
>   

OK

> Hmm. Good question. I think it should, but this means that we should
> address the requirements that the API pose to sendmsg() in the document.
>
> Or, we may define another API for application to request validation (in
> terms of reachability check) for a given locator. This in turn means
> that we need additional error code for the case when the app requests
> for using a specific peer locator which is not verified (in terms of
> reachability check), which indicates that a reachability check is needed.
>
> Any comments?
>   

It seems a bit weird for sendmsg to block, but I'm not the API expert... 
anyway, I have a slight preference for your second design from above.

> I am afraid that socket option number is not under the control of IANA.
> For instance, when I checked some IPv6-related socket options on
> different plantforms (Linux and BSD), they are different. So, in my
> understanding, there is no IANA consideration in terms of socket option
> numbers. W.r.t socket level, I am not completely sure if it is under the
> control of IANA. Browsing the system include files on Linux and BSD, it
> *seems* to me that it's common to follow the IP protocol number. For
> instance, SOL_TCP is 6.
>
> Maybe I am missing something. Any comments?
>   

I'm sure you are right, but I would like the IANA considerations to note 
that the socket option numbers are NOT under IETF or IANA control, and 
that they are platform-specific.

> W.r.t. the definition of a unknown destination locator, it is given in
> Section 2 (Terminology) as below, so I think it is clear.
>   

Hmm... reading on...

>>       *  Unknown locator - Any locator that does not appear in the
>>          locator list of the shim context associated with the socket.
>>          When there is no shim context associated with the socket, any
>>          source and/or destination locator requested by the application
>>          is considered to be unknown locator.
>>     
>
> Speaking from SHIM6's perspective, it does not make any sense to allow
> the application to send packet to a unknown locator.

I agree with this.

> Peer's locator set
> is provided by the peer, and a node cannot propose peer's locator. I
> believe it's the same for HIP. Let me clarify this point with Miika
> off-line.
>   

OK. I think the simplest solution would be to simply forbid the API user 
from inserting unknown locators. If you want to go beyond that it is of 
course possible, but will complicate things.

Jari

---

From: Miika Komu <[email-masked]>
Date: Mon, 11 Oct 2010 11:59:40 +0300

Hi,

> course possible, but will complicate things.

it is a very useful feature if the application can provide at least the 
initial mapping from the destination HIT to the corresponding IP 
address. Contrast to SHIM6, HIP does not have routable ULIDs...

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 12 Oct 2010 00:45:06 +0900

Hi Miika,

> address. Contrast to SHIM6, HIP does not have routable ULIDs...

Could you please tell me what is the current practice? How the 
destination IP address (locator) is determined on the initiator in 
normal case?

I assume that the kernel first knows the peer's IP address (locator) 
from the DNS. If there are more than one IP address returned, then the 
kernel will pick one, I assume. What motivates application to specify 
the initial peer locator? Why it's *very* useful for application to 
specify the address?

Regards,
Shinta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Oct 2010 10:35:24 +1300

> destination IP address (locator) is determined on the initiator in

RFC 3484, or whatever the implementor has chosen to do if they
don't like RFC 3484.

    Brian

> _______________________________________________
> shim6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shim6
>

---

From: Miika Komu <[email-masked]>
Date: Tue, 12 Oct 2010 07:15:12 +0300

Hi,

> RFC 3484, or whatever the implementor has chosen to do if they

yes, in the case of multiple destination locators, this could be used. 
At the moment, I am just more concerned that there is no locators at all.

>> the initial peer locator? Why it's *very* useful for application to

There's three problems associated with this.

First, this would assume that the resolver is HIP capable (i.e. can 
resolve HIP records from DNS) but this requirement has not been included 
in the draft at all. While the HIP implementations are offering such 
service for the OS, this is not a standard service implemented by the 
operating system.

Second, the draft is defining *native* APIs for SHIM layers but the 
draft is still assuming legacy resolving APIs underneath while I would 
like to make them independent of each other:

http://tools.ietf.org/html/rfc5338#section-3.2

Third, the native HIP API draft is in the RFC editor queue and it is 
assuming that this feature is available for multiple use cases as 
clearly stated here:

http://tools.ietf.org/html/draft-ietf-hip-native-api-12#section-4.6

Another use case for supporting initial peer locators is P2P-SIP with 
HIP support, for which, there are two implementations (HIIT and 
Ericsson). There, the locator information can be derived from the SIP 
messages. DHT messages or perhaps even from SRV records from the future 
(which aren't supported by any of the HIP resolver software yet) instead 
of the standard HIP records.

So, we have a long story behind the "MAY":

"If the shim sub-layer turns out to be HIP, the HIP implementation MAY 
accept the request for using unknown destination locator"

So, I would suggest to keep it there or maybe even change it to SHOULD.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 12 Oct 2010 10:54:40 -0700

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]]
> Sent: Friday, October 08, 2010 4:35 AM
> To: Jari Arkko
> Cc: Shinta Sugimoto; shim6; [email-masked];
> Henderson, Thomas R
> Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
>
<snip>

> give a hint especially in the absence of better knowledge

I agree; that was my understanding of the main intent of this clause (to allow the application to provide the shim with a hint of the binding to IP address).

However, in reviewing section 6.2, it seems like this would fail since there is no shim context for the socket.  If I'm not mistaken, the draft seems to forbid applications running in opportunistic HIP mode because this API requires that shim context be associated with the socket for the ancillary data to be accepted.

> identifier-locator Split, Samu Varjonen et al, 2009

The paper does point out a use case for sending data to a previously unknown locator-- however, it seems to be slightly different than the use case here.  In the paper, the node learns of the address change and it seems that the HIP daemon sends an Echo request-- I take this to mean that the HIP daemon does this proactively.  Here, we are talking about applications triggering this directly and using this API to do so since they may have learned of the address out of band?

Regarding Section 13.1.2 (also sections 5.9, 5.11, 6.2-- anywhere that EINVALIDLOCATOR is being returned on a destination address), this discussion triggered some questions in my mind as to how this is assumed to work.  If an application proposes some peer locators to the shim, should the setsockopt or sendmsg calls block until the addresses are verified?  If the socket is non-blocking, should sendmsg() return EWOULDBLOCK if the locator is unverified?  Note that it may be clearer to refer to them as unverified rather than unknown locators, in the case of destination addresses.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Wed, 13 Oct 2010 07:59:56 +0300

Hi,

On 12/10/10 20:54, Henderson, Thomas R wrote:

>> -----Original Message----- From: Miika Komu
>> [mailto:[email-masked]] Sent: Friday, October 08, 2010 4:35 AM To:
>> Jari Arkko Cc: Shinta Sugimoto; shim6;
>> [email-masked]; Henderson, Thomas R Subject: Re:
>> [shim6] AD review of draft-ietf-shim6-multihome-shim-api
>>
> <snip>
>
>> 1. No HIP session (i.e. SHIM context) yet and application knows the
>> IP address of the peer. 2. An existing HIP session, connectivity
>> lost but the application (with the assistance from the user) can
>> help to rediscover the peer.
>>
>> Now remembering this "unknown" part again, I think the MAY was
>> referring to the first case described above. It should be ok for
>> the application give a hint especially in the absence of better
>> knowledge from the SHIM.
>
> I agree; that was my understanding of the main intent of this clause
> (to allow the application to provide the shim with a hint of the
> binding to IP address).
>
> However, in reviewing section 6.2, it seems like this would fail
> since there is no shim context for the socket.  If I'm not mistaken,
> the draft seems to forbid applications running in opportunistic HIP
> mode because this API requires that shim context be associated with
> the socket for the ancillary data to be accepted.

right:

"Another use case is to use the opportunistic mode.."

>> Regarding to the case two, it is true that RFC5206 basically
>> assumes that the peer has to announce it's locator set before the
>> local host can use them. I believe the peer can refuse to answer if
>> the local host triggers a return routability check to an
>> unannounced locator of the peer. However, the situation may be
>> changing in RFC5206-bis due to the recent advancements in IPv4-IPv6
>> handovers [1] which are not yet included in RFC5206.
>>
> The paper does point out a use case for sending data to a previously
> unknown locator-- however, it seems to be slightly different than the
> use case here.  In the paper, the node learns of the address change
> and it seems that the HIP daemon sends an Echo request-- I take this
> to mean that the HIP daemon does this proactively.  Here, we are
> talking about applications triggering this directly and using this
> API to do so since they may have learned of the address out of band?

I stand corrected, setting the destination address should be possible 
only in the beginning of HIP communications between two hosts.

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 13 Oct 2010 17:34:55 +0900

Hi Thomas and Miika,

Thanks for your comments and clarifications. Please find my comments inline.

> However, in reviewing section 6.2, it seems like this would fail since there is no shim context for the socket.  If I'm not mistaken, the draft seems to forbid applications running in opportunistic…

Yes, that is correct. We specify that there must be shim context 
associated with the socket. Otherwise, the socket option does not take 
effect. Removing the requirement (i.e., removing a need to have an 
associated shim context with the socket) will cause problems I think. 
For instance, it is impossible for the kernel to return error code 
(e.g., EINVALIDLOCATOR) when the setsockopt() is called as the kernel 
has no idea about the peer's locator set. So, I think we should not 
change that.

Another design principle that we applied to the API is that the socket 
must be "connected" so that the socket options to take effect. This is 
because it is impossible for the kernel (more specifically, the 
multihoming shim sub-layer) to return the result of the request made by 
the application because the kernel has no idea about the EID pair (note 
that EID pair is known by the kernel when the application actually sends 
data in the case of unconnected socket). I don't think we should change 
the design principle either.

Talking about the HIP case we are discussing now, I think there is a 
contradiction. The API requires that the socket must be "connected". 
However, the socket is supposed to be in a unconnected status when the 
application issues the API call to specify the peer locator because the 
HIP exchange has not been taken place yet. Maybe I am missing something 
here. If so, please correct me.

For the above reason, I think that we cannot use SHIM_LOC_LOCAL_SEND 
socket option (or ancillary data) for the purpose of specifying the 
initial peer locator for the HIP case.

If there is a need for application to specify the initial locator, it 
should be a defined separately, I think. And that is HIP specific. The 
scope of this document is to define a *common* set of API required for 
HIP and SHIM6, so I think it's outside the scope of this document. Comments?

> The paper does point out a use case for sending data to a previously unknown locator-- however, it seems to be slightly different than the use case here.  In the paper, the node learns of the addre…

I wonder how the kernel does not know about the peer locator (IP 
address) but the application does. You mentioned that application could 
know the address out-of-band, but how? Do you have good examples?

> Regarding Section 13.1.2 (also sections 5.9, 5.11, 6.2-- anywhere that EINVALIDLOCATOR is being returned on a destination address), this discussion triggered some questions in my mind as to how thi…

Yes, I think you are right. This was pointed out by Jari too and I plan 
to update the draft by defining another error code (to distinguish 
invalid locators in the security (HBA) sense from invalid locators in 
reachability sense).

Regards,
Shinta

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 13 Oct 2010 07:23:12 -0700

> Sent: Tuesday, October 12, 2010 10:00 PM
> To: Henderson, Thomas R
> Cc: Jari Arkko; shim6; [email-masked]

Yes, but the HIP native API draft does not say anything about
overriding the rules in the shim6 API specification concerning
the need for shim context.  Maybe that should be clarified in
the HIP API draft.

- Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 13 Oct 2010 07:39:28 -0700

> From: Shinta Sugimoto [mailto:[email-masked]]
> Sent: Wednesday, October 13, 2010 1:35 AM
> To: Henderson, Thomas R
> Cc: 'Miika Komu'; Jari Arkko; shim6; [email-masked]
> > I agree; that was my understanding of the main intent of
> this clause (to allow the application to provide the shim
> with a hint of the binding to IP address).
> >
> > However, in reviewing section 6.2, it seems like this would
> fail since there is no shim context for the socket.  If I'm
> not mistaken, the draft seems to forbid applications running
> in opportunistic HIP mode because this API requires that shim
> context be associated with the socket for the ancillary data
> to be accepted.
>

My sense is that it would be OK to proceed in that manner but that
we probably need to take a pass through this document and the
HIP API document to make sure that the scope and relationship
between the documents is clearer.

An analogous situation is present in normal sockets in which
the common socket API has different semantics when the underlying
transport is datagram or stream.  In that case, there is a family
of functions (e.g. getprotoent) that can report to the client
what type of socket it is.  I am wondering whether SHIM_ASSOCIATED
should be expanded along those lines to tell the client what
underlying shim type is present (or whether the rules for
shim context apply or not).

> > The paper does point out a use case for sending data to a
> previously unknown locator-- however, it seems to be slightly
> different than the use case here.  In the paper, the node
> learns of the address change and it seems that the HIP daemon
> sends an Echo request-- I take this to mean that the HIP
> daemon does this proactively.  Here, we are talking about
> applications triggering this directly and using this API to
> do so since they may have learned of the address out of band?
>

I don't have any concrete examples since I don't know of
any (presently) shim-aware applications, but it is not hard
to conceive of one in which well-known IP/HIT bindings are
added to an application configuration file for bootstrapping
purposes.

- Tom

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 14 Oct 2010 12:01:54 +0900

Hi Thomas,

Henderson, Thomas R wrote:

(snip)

> between the documents is clearer.

OK.

> shim context apply or not).

It depends on value that application could get by knowing the type of 
multihoming shim sub-layer (i.e., HIP or SHIM6). I personally cannot 
come up with good usecases.

> added to an application configuration file for bootstrapping

OK, I see. Thanks for the clarifications.

Regards,
Shinta

---

From: Miika Komu <[email-masked]>
Date: Thu, 14 Oct 2010 07:35:15 +0300

Hi,

> the need for shim context.  Maybe that should be clarified in

I think it would have been simpler to keep the exception in the SHIM6 
draft rather than changing the HIP draft which is in editor queue 
(blocked by the SHIM6 draft)?

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 13 Oct 2010 21:59:54 -0700

> Sent: Wednesday, October 13, 2010 9:35 PM
> To: Henderson, Thomas R
> Cc: shim6; [email-masked]

You raise a good procedural point; I would also be fine with editing the shim6 draft if Shinta is OK with it.

- Tom

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 14 Oct 2010 14:29:03 +0900

Hi Miika and Thomas,

> You raise a good procedural point; I would also be fine with editing the shim6 draft if Shinta is OK with it.

I see.

I would like to keep the socket option (to specify the initial locator, 
i.e., where to send I1 message) separate from SHIM_LOC_PEER_SEND because 
they are semantically different. Are you fine with adding a socket 
option something like SHIM_INITIAL_PEER_LOCATOR in the multihome shim 
API document (this one)? The socket option can be described as follows:

- The socket option allows application to specify the destination IP 
address to send HIP I1 message.
- This socket option is accepted only when the multihoming shim 
sub-layer is HIP. Otherwise, EOPNOTSUPP is returned.
- There is no specific requirements about the type of socket to which 
the setsockopt() is called (but it should be in an unconnected state as 
I mentioned in my previous email).
- There is no specific requirements about the presence of shim context 
associated with the socket either. (but there should be no shim context 
associated with the socket because the socket option is supposed to be 
called at the very beginning of the session)

Please let me know if the above sounds reasonable to you, Miika and Thomas.

Regards,
Shinta

---

From: Miika Komu <[email-masked]>
Date: Thu, 14 Oct 2010 23:20:49 +0300

Hi,

>> use case here. In the paper, the node learns of the address change and
>> it seems that the HIP daemon sends an Echo request-- I take this to
>> mean that the HIP daemon does this proactively. Here, we are talking
>> about applications triggering this directly and using this API to do
>> so since they may have learned of the address out of band?
>

yes, as I explained earlier:

http://www.ietf.org/mail-archive/web/shim6/current/msg02203.html

---

From: Miika Komu <[email-masked]>
Date: Thu, 14 Oct 2010 23:46:17 +0300

Hi,

On 10/14/2010 08:29 AM, Shinta Sugimoto wrote:
> API document (this one)?

procedurally, I'm not really fine with this because then we have to 
change anyway the native HIP API. It is already referring to 
SHIM_LOC_PEER_PREF, SHIM_LOCLIST_PEER and SHIM_LOC_PEER_SEND:

Technically, I am not convinced if having a separate constant for 
initial locator is really needed.

It seems that we have the following options:

1. Override the statement in the native HIP API draft
2. Remove the statement in the SHIM API
3. Cross-reference the native HIP API draft
4. Document the exception for HIP in the SHIM API

I would be in favor of 2 and perhaps 3. What about others?

> The socket option can be described as follows:
>

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 15 Oct 2010 13:41:22 +0900

Hi Miika,

> http://tools.ietf.org/html/draft-ietf-hip-native-api-12#section-4.6

Ok, I read section 4.6 of the HIP Native API document.

> initial locator is really needed.

Well, the feature is the same. But the requirements and pre-requisites 
are different. Anyway, let's resolve this.

> I would be in favor of 2 and perhaps 3. What about others?

By 2, you mean updating the texts in the SHIM API document, correct?

What about updating the texts for Section 13.1.2 (replacing the second 
paragraph) as follows:

If the shim sub-layer turns out to be HIP, the HIP implementation MUST 
reject the request (SHIM_LOC_PEER_SEND as cmsg_type) for using a unknown 
destination locator. There is, however, an exceptional case where the 
HIP implementation SHOULD accept the request provided that the message 
to be sent by sendmsg() contains an I1 packet. In this exceptional case, 
the kernel SHOULD accept the request even if there is no shim context 
associated with the socket.

Does this sound reasonable?

Regards,
Shinta

---

From: Miika Komu <[email-masked]>
Date: Sat, 16 Oct 2010 13:47:47 +0300

Hi Shinta,

> By 2, you mean updating the texts in the SHIM API document, correct?

yes, by removing the statement:

> Does this sound reasonable?

It does, except why do we need to restrict to sendmsg()? I would also 
suggest the following changes:

* s/implementation/layer/
* s/kernel/HIP layer/
* s/constains an I1 packet/would be used to initiate a key exchange by 
the HIP layer/

---

From: Shinta Sugimoto <[email-masked]>
Date: Sun, 17 Oct 2010 00:01:05 +0900

Hi Miika,

(10/10/16 19:47), Miika Komu wrote:

(snip)

> It does, except why do we need to restrict to sendmsg()?

Because it is possible to distinguish the exceptional case from the 
normal case. Suppose you allow it by setsockopt(). How do you 
distinguish the two cases? I have no idea how to do it.

> I would also

OK.

> * s/constains an I1 packet/would be used to initiate a key exchange by

Let me clarify. Do you foresee other data than I1 packet which would 
trigger the HIP key exchange? I thought it is the HIP daemon who uses 
the ancillary data (SHIM_LOC_PEER_SEND as cmsg_type) to send the I1 
packet to a designated locator. Or, is it the application that uses the 
socket option to send user data to a designated locator? If so, how can 
the kernel distinguish the exceptional case from the normal case? Note 
that the suggested text is saying that normally the kernel must reject 
the request if there is no shim context associated with the socket.

Regards,
Shinta

---

From: Miika Komu <[email-masked]>
Date: Mon, 18 Oct 2010 09:39:04 +0300

Hi Shinta,

> distinguish the two cases? I have no idea how to do it.

can you remind why it needs to be distinguished? If there's no reason, 
what about:

There is, however, an exceptional case where the HIP layer SHOULD accept 
the request. The case occurs when there is no context or the HIP state 
machine is in UNASSOCIATED state. In this exceptional case,
the socket layer SHOULD accept the request.

> the request if there is no shim context associated with the socket.

Please note that I1 in this context is misleading because it sounds like 
the application is sending the I1 (where as it should hipd sending it).

There's actually a case where there's no need to send I1:

https://tools.ietf.org/html/draft-ietf-hip-hiccups-05

I believe the suggested text above should cover it too, but we shouldn't 
be too specific about it because it's functionality uncommon between 
SHIM6 and HIP.

---

From: Shinta Sugimoto <[email-masked]>
Date: Mon, 18 Oct 2010 19:15:33 +0900

Hi Miika,

(snip)

> can you remind why it needs to be distinguished? If there's no reason, 

The exceptional case needs to be distinguished from the normal case 
because we accept SHIM_LOC_PEER_SEND when there is no shim context 
associated with the socket. And we have good reason to limit the usage 
of the socket option to the cases where there is a shim context 
associated with the socket.

> the socket layer SHOULD accept the request.

To WG members: please note that I had phone discussion with Miika and 
came to a common understanding that the following text would suffice:

There is, however, an exceptional case where the HIP layer SHOULD accept 
the request provided that the HIP association is in UNASSOCIATED state. 
In this exceptional case, the socket layer SHOULD accept the request.

> be too specific about it because it's functionality uncommon between 

OK. I now understand that you are talking about the case where 
application provides a kind of hints to the HIP daemon about the initial 
locator by writing data to the socket.

Regards,
Shinta

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 19 Oct 2010 07:38:30 -0700

> In this exceptional case, the socket layer SHOULD accept the request.

I'm OK with the above wording.  I think it would be clearer to also refer to section 4.6 of the HIP native API draft (as Miika suggested) where this is explained in more detail, but I noticed that you don't already have the native API draft in the list of references.  Are you trying to avoid the draft dependency?

- Tom

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 20 Oct 2010 18:48:13 +0900

> I'm OK with the above wording.  I think it would be clearer to also refer to section 4.6 of the HIP native API draft (as Miika suggested) where this is explained in more detail, but I noticed that…

Thanks for your comment. Yes, I agree that we should add a reference to 
the Section 4.6 of HIP native API document. No, I am not trying to avoid 
any dependency.

Now I am updating the document and I will submit it as soon as possible.

Regards,
Shinta