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

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

Hi Francis,

Please find my further comments inline.

On Wed, 02 Aug 2006 13:03:01 +0200
Francis Dupont <Francis.Dupont@point6.net> wrote:

>  In your previous mail you wrote:
> 
>    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?
>    
> => yes, this is the main issue.

Ok.

>    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).
> 
> => yes, it is the other side of SHIM6/IPsec interactions.
> 
>    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?
> 
> => it is always the case: as the BITW is at the wire level it has
> only access to the bits on the wire.

Ok.

>    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.
> 
> => as IPsec and BITW is already part of the IP architecture, SHIM6
> has to accomodate with them.

Yes, I agree in general.  But I need more clarification on this
issue.  More comments below.

> 
>    BTW, according to RFC4301, BITW device itself
>    is IP addressable normally.
> 
> => yes, it has to be managed and perhaps to run IKE so it is better
> to give it its own address. BUT this doesn't mean it is a router
> (a security gateway in IPsec terminology).

Ok.

>    If this is the case, I tend to think
>    that support by SHIM6 does not make much sense in those scenario,
>    meaning that the concern is not serious.
> 
> => I strongly disagree: there is no requirement to make IPsec BITWs easy
> but there is a clear requirement to be compatible (i.e., not to make
> them impossible).

I am not saying that we should give up providing the compatibility.
I am saying that we should first take a look at the problem, and
see how serious the problem is.  I am not sure if the combination
of SHIM6 and BITW IPsec is totally infeasible or not, so I need
clarification.

I see similarity of BITW and SHIM6 in a sense that both of them
are intermediation of an IP processing.  And when designing such
intermediation, the primary concern is to keep it transparent to
its upper layer protocols.  In this respect, SHIM6 does not have
any issue as far as I see it, and (I hope) we all agree with that.

Now we are trying to see what kind of impact would SHIM6 (a new
intermediation) would have on another already-existing
intermediation which is BITW IPsec.

Based on assumption that BITW IPsec should be completely transparent
to the ULPs (including SHIM6 as its a conceptual sublayer within IP
layer), I don't see why SHIM6 over BITW IPsec would not work.  Well,
it would not be optimum operation, but that's same in the case of
normal IP host connected to multihomed site over BITW device isn't it?
(Please correct me if I am wrong)  To me, what you are pointing out
is that SHIM6 and BITW may work more efficiently, hence I see it
rather optimization than satisfying mandatory requirement.  And I
am of course not against considering the optimization.

> 
>    Anyway, if the concern is really serious,
> 
> => it is, I expect you don't want a last call objection from the military
> community and its vendors against the protocol document?

No.  My intention is to capture the issue.

>    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?
>    
> => one way is to put the ULID in all packets. This solves this problem
> and related firewall issues too (*). But it is clearly expensive.

Yes.

>    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).
> 
> => yes, this is the IPsec VPN tentation but multi-homing is very different
> because the standard/initial mode hides nothing...

Ok. I see the difference.

>    So, I am feeling that there is no solution that fulfills everyone's
>    requirement.  We should focus on the main target, IMHO.
>    
> => the main target is to have a protocol which fits into the current
> architecture (note this is not yet the case) and solves the problem
> (still need to be proved).

I agree with your statement, in general.  But I would like to see if
the problem that we are talking about is a problem newly created by
the SHIM6 intermediation, or a general (existing) problem which may be
potentially solved by optimization.

> Two other points:
>  - one possible solution is to integrated the whole SHIM6 into the BITW
>    device (i.e., have an IPsec+SHIM6 BITW). As the issue comes from the
>    relative positions of the IPsec and SHIM6 sublayer, this makes sense.

This is an approach to combine two different intermediation into one.
I see no reason to prohibit this option.

>  - (*) in MIPv6 the home address is in all packets and fragments for the
>    benefit of firewalls (cf RFC 3775 6.3 page 53). IMHO SHIM6 has the same
>    concern so a packet or fragment should be easily attached to a
>    communication (here easily means without SHIM6 signaling spoofing,
>    state handling, etc, both because it is clearly not so easy and
>    because one can't assume an intermediate node can see all packets).

Ok, noted.


Regards,
Shinta