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

Jari Arkko <> Sun, 10 October 2010 21:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18FB03A67E2 for <>; Sun, 10 Oct 2010 14:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.15
X-Spam-Status: No, score=-100.15 tagged_above=-999 required=5 tests=[AWL=-2.139, BAYES_00=-2.599, FRT_STOCK2=3.988, J_CHICKENPOX_102=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4FvqvBH5D57I for <>; Sun, 10 Oct 2010 14:22:34 -0700 (PDT)
Received: from ( [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id 9CE903A67AB for <>; Sun, 10 Oct 2010 14:22:33 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4ADB12CC3B; Mon, 11 Oct 2010 00:23:40 +0300 (EEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wdYYJydV2dRh; Mon, 11 Oct 2010 00:23:39 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id C3C662CC2F; Mon, 11 Oct 2010 00:23:38 +0300 (EEST)
Message-ID: <>
Date: Mon, 11 Oct 2010 00:23:37 +0300
From: Jari Arkko <>
User-Agent: Thunderbird (X11/20100411)
MIME-Version: 1.0
To: Shinta Sugimoto <>
References: <20100816114202.1241.59079.idtracker@localhost> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>, Kristian Slavov <>
Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 10 Oct 2010 21:22:36 -0000


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


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


>>> * Preferred locator - The (source/destination) locator currently
>>> used to send packets within a given context. As defined in
>>> [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...
> 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.


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

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

>> Can you specify what is the difference to SHIM_LOC_LOCAL_PREF? One sets
>> the preference, the other forces a choice?
> 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:
> 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.

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

>>> /* 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.
> 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.

>>> 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?
> In the absence of REAP, the EOPNOTSUPP error code should be returned to
> the app. Let me add this.


>>> 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 <>], [RFC5535
>>> <>].
>> Please specify what kind of return routability is being employed, do you
>> specifically mean REAP and the corresponding checks in HIP?
> Yes. Let me update the texts accordingly.


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

>>> This document contains no IANA consideration.
>> Really? Where are the various socket option number spaces allocated?
> 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.

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