visibility of identifier in shim6 payload packet (was: Re: IPsec !?...)

[Shinta Sugimoto <shinta@sfc.wide.ad.jp>]

Hi Francis,

(excuse me for changing the subject, but I think it's more
suitable for the topic being discussed)

Please find my comments below.

On Tue, 01 Aug 2006 13:29:07 +0200
Francis Dupont <Francis.Dupont@point6.net> wrote:

>  In your previous mail you wrote:
> 
>    > To make the use of IPsec impossible as a limited alternative is more
>    > arguable. To make shim6 and IPsec compatible is a third topics, the
>    > question was opened by Jim and is not yet closed.
>    
>    i don't see any problems with IPSec and shim compatibility.... do you 
>    see any issues/troubles there? could you expand on this?
>    
> => you can read the thread initiated by Jim. To summary there is an issue
> about what should be the traffic selectors and how to implement a BITW
> (Bump-in-the-Wire, cf. RFC 4301). As it was already discussed in this
> list please send questions directly to me (but solution(s) to the list :-).

I have read the email thread, but still I am not completely sure if
I understand your point.  So, let me clarify.

I assume that you are pointing out the visibility of the identifier
in the data packet.  In case of SHIM6, if locator switch is performed
at the SHIM layer, the source and destination address field of the
IP header contain locators not the identifiers (in some case they
might be identical, though).  Now, what implications would this have
for existing IPsec system?  I assume your point is that BITW IPsec
device will not be able to extract the information from the IP packet
for protecting the traffic.  More specifically, BITW IPsec stack may
want to take the traffic selector information from the packet.
In this respect, there is a difference between MIP6 RO and SHIM6 in
its relation to the IPsec.  In case of MIP6, the identifier (=home address)
is contained in the extended field of the IP header (either in RH2
or DSTOPT).  Not in SHIM6 case.  Is this the problem that you are
pointing out?

Now, let me state my view on this.  I think that the current
architectural model given in the SHIM6 base protocol document is
fairly reasonable, and I think we should not change it.
And I think the above issue is not relevant to security mechanism
of the SHIM6 protocol (that's why i changed the subject).
Moreover, I would see the above case (BITW) rather minor than
major.  However, I should admit that I am not familiar with the
real deployment of BITW IPsec and how common it is to extract
the information from the packet reached to the BITW device.
Could you provide me some input how common it is in the BITW
IPsec scenairo to dynamically extract the information from the
IP header of the packet?  We may also think how much does it
make much sense to run SHIM6 in case where the BITW device is
attached to the host.  BTW, according to RFC4301, BITW device itself
is IP addressable normally.  If this is the case, I tend to think
that support by SHIM6 does not make much sense in those scenairo,
meaning that the concern is not serious.  Anyway, if the concern
is really serious, then we may consider minor modification to
the SHIM6 payload extension header so that it can provide
identifier information for the BITW IPsec.  What do you think?

BTW, in case of MIP6, due to the visibility of the identifier
information, some people are feeling privacy concern and trying
to hide them from the packet on the wire (in MOBOPTS IPRG).
So, I am feeling that there is no solution that fulfills everyone's
requirement.  We should focus on the main target, IMHO.


Regards,
Shinta