[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: ipsec error protocol
>To: sommerfeld@east.sun.com
>Cc: ipsec@lists.tislabs.com
>Subject: RE: FW: ipsec error protocol
>
>
>
>-----Original Message-----
>From: sommerfeld@thunk.east.sun.com
>[mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld
>Sent: Sunday, January 28, 2001 7:29 PM
>To: sankar ramamoorthi
>Cc: sommerfeld@east.sun.com; ipsec@lists.tislabs.com
>Subject: Re: FW: ipsec error protocol
>
>
>
>> >Existing implementations I'm familiar with don't do (b), and adding
>> >this mapping is non-trivial because multiple equivalent SA's may exist
>> >between a pair of communicating nodes.
>>
>> Yes - this would be a problem.
>>
>> How are the SAs distributed between the pair of communicating nodes?
>
>IKE.
I think there is some context missing here. What I said was w.r.to
the following comment
>>> b) the implementation maintains a linkage between the "inbound" and
>>>"outbound" SA's
>>>
>>>Addressing each of these in turn:
>>
>>>If you have redundant tunnels and are running dynamic routing over
>>>them (and before you dismiss this as unlikely, I know people who have
>>>talked seriously about deploying just this), then due the vagaries of
>>>dynamic routing, the traffic flow over any given tunnel may be
>>>unidirectional..
>>
>>>Existing implementations I'm familiar with don't do (b), and adding
>>>this mapping is non-trivial because multiple equivalent SA's may exist
>>>between a pair of communicating nodes.
>>
I presumed that when you were talking about separation of inbound SA
and outbound SA, you are discussing some kind of fault-tolerant system
where the multiple negotiated SAs are distributed to backup(s) and
some kind of separation between inbound and outbound SA is also
maintained for loadbalancing purposes between primary and backup(s).
>> Could'nt the same channel be used to keep information in sync.
>
>We were discussing how to extend ike to allow for this when you
>claimed it was a layering violation.
By channel, I meant the FT channel (see my assumptions above).
Yes, I still feel that we should first try to fix ipsec problem
at ipsec level.
-- sankar --
References: