[anonsec] btns-ipsec-apireq.txt

[Shinta Sugimoto]

Hi Michael,

please find my comments inline.

On Sat, 22 Apr 2006 19:08:13 -0400
Michael Richardson <mcr at sandelman.ottawa.on.ca> wrote:

> 
> >>>>> "Shinta" == Shinta Sugimoto <shinta at sfc.wide.ad.jp> writes:
> 
> (when I first read your name, I was sure it must be "Shim6ta Sugimoto"...)
> 
>     >> If I understood correctly, it seems like shim6 guys are interested in
>     >> the interactions between applications, locators, referrals, resolver
>     >> and shim module.  We have touched those topics in the native HIP API
>     >> work, but there is still a bunch of things to be done.
> 
>     Shinta> Yes, now I am sorting out what kind of API is needed for SHIM6.
>     Shinta> In SHIM6, the issues are mainly how app can easily/efficiently
>     Shinta> deal with locators, and interaction between SHIM6 module and ULP
>     Shinta> (especially TCP) should also be defined.  But certainly there is
>     Shinta> a relation to other API works (including the work done in HIP).
> 
>   I am perhaps someone naive in my understanding of shim6. 
>   I followed multi6, and was well briefed over dinner at the last IETF as to
> how shim6 works. I must be admit that I'm at a loss to understand the shim6
> API question, when it is not being used to bootstrap to HIP.
>   
>   As I understand it, upon initial connect, the application is going 
> (via getpeername/getsockname), going to see the address that was used to
> connect to it, and the local address to which the connection was made.
> 
>   Should the shim6 layer detect a loss of connectivity and switch to another
> address, the transition will be not be seen to the application.  Is it an 
> open question what getsockname/getpeername() will say after the transition?

No.  IMO, getsockname()/getpeername() should not be affected by the
locator change.  If SHIM6 context is applied to given flow, then locator
changed to something else, that should be kept invisible to the ULP.

>   i.e. is the kernel supposed to maintain the original fiction,

Yes.

> or is it
> better that it indicate what is reality at that moment, so that if the
> purpose of the query was to start a second connection (i.e. FTP...) that
> it can start with a better hint.

Apart from the above (that the locator change should not affect
getsockname()/getpeername()), telling the 'reality' of the locator
selection to the ULP might be helpful.  Not sure how much is it helpful
though.  Such extension would allow application to get information
about the locator which is bound to given socket.  Similary, we may
extend sendmsg()/recvmsg() to deliver locator information to the
application storing them in acillary data, for instance.  But again,
I don't see clear need (good usecase) for that.  Do you see any ?

>   I can see how getsockname()/getpeername() are not good enough, and you'd
> like a more sophisticated answer. This is similar, certainly to what IPsec
> wants: we want to know far more than what that interface can provide.
>   (And in the case IPv4 transport mode through a NAPT, the answer from
> getpeername() is perhaps completely ambiguous)

I see.  BTW, is there any other cases than NAT where IPsec requires
more sophisticated Socket API calls if peer is multihomed ?

>   Is that the extent of the requirements?

Yes, I think so.

>   Or are there more?

Not sure at the moment.


Regards,
Shinta