[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



 In your previous mail you wrote:

   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.
   
=> note that we have the architectural point of view (i.e., Jim's
concern) which is the same issue but with another kind of arguments.

   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.

=> what do you mean with SHIM6 over BITW IPsec? Don't forget the kind
of IPsec implementations is transparent too, i.e., the provided service
is the same, and in particular the traffic selectors are the ULIDs when
the device fiddles about the bits in the wire.

    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)

=> I can't say: I don't understand your idea.

   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,

=> it is created by SHIM6 because, even we can consider it is a bad design,
IPsec needs to find its traffic selectors in the traffic packets and
the choice to put IPsec at an upper level than SHIM6 in the stack is
bot incompatible with an IPsec device running at the wire level and
raises a basic architectural issue on how IPsec knows the locators/ULID
binding.

Regards

Francis.Dupont@fdupont.fr