[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Selection of proposals
At 10:46 PM 11/4/98 -0500, you wrote:
>I'm a bit confused by your example.
>
>You say that "During IKE negotiation, SG1 sends out the SAPayload(with
the two
>transforms it has) to SG2 and H2." There are two separate IKE SAs here, SG1
>to SG2 and SG1 to H2, so neither to these responders sees the other's
>negotation.
rohit>>
Yes! thats right, what i wanted to tell was SG1 (in quick mode) will
form a seperate SAPayload (SAPayload1) to SG2 with two transforms. First
one ESP with 3DES and second one ESP with DES. It also sends out another
SAPayload (SAPayload2) to H2 with two transforms in it, first AH with SHA1
and secondly AH with MD5. SG2 will select the first transform in SAPayload1
as ESP with 3DES will match the first transform available with it. H2 will
select the 2nd transform AH with MD5 in SAPayload2.
Now SG1 finds that SG2 has selected the first proposal and H2 has
selected the 2nd proposal, now what SG1 should do ?
Because of this, an SA bundle that perfectly matches the proposal cannot be
formed by SG1. However, SG2 is
capable of processing with DES and had SG2 selected this, it could have
formed an SA bundle at SG1.
>It is up to SG2 to negotiate appropriate SAs for both of these
>endpoints.
>Also, we do not require support for the specific example you
>cited, because you have two nested tunnels with a common endpoint. This is
>not a required combination according to the arch doc, a simplification made
>at the request of other implementors last year.
rohit>>
But the "draft-ietf-ipsec-arch-sec-06.txt" has the following paragraph on
page 13, here also two tunnels are ending at a common endpoint i suppose..
2. one endpoint of the SAs is the same -- The inner and
outer tunnels
could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
| |
Gwy 1 Gwy 2 |
| |
| |
| ----Security Association 1 (tunnel)----
|
| |
---------Security Association 2 (tunnel)-------------
*****************
I am giving here the scenerio from last mail for easy reference .....
>> If we have SG1, SG2 and IPSec capable host H2 in the following
>>scenario,
|--------ESPtunnel---- |
| |
SG1 ----------------- SG2 ----------- H2
| |
|------------------AH Tunnel-----------|
>>and the security policies are as follows.
>>At SG1 OutBound Policy is
>> Proposal #1:
For SG2 : ESP with 3DES
or ESP with DES
For H2 : AH with SHA1
or AH with MD5
>>At SG2 we have the Inbound Policy as
Proposal # 1 :
ESP with 3DES
or ESP with DES
>>H2 has the inbound policy as
Proposal # 1:
AH with MD5
>>During IKE negotiation, SG1 sends out the SAPayload(with the two
>>ansforms it has) to SG2 and H2. SG2 will select Transform #1 of SG1 and
>> will select Transform # 2 of SG1. Because of this, an SA bundle that
>>perfectly matches the proposal cannot be formed by SG1. However, SG2 is
>>capable of processing with DES and had SG2 selected this, it could have
>>formed an SA bundle at SG1.
>>Do we just reject the proposal at this stage or is it permitted to send the
>>two transforms as different proposal payloads in independent SA payloads
>>and try to see if a match can be found amongst all available proposals? The
>>problem here is, of course, the fact that H2 and SG2 look at the individual
>>and independent SPDs while SG1 looks at the combined SA bundle.
*************************************************************************
-: Bridging The Gap Between Software And Hardware :-
Rohit Aradhya Ph : (040)7742606
Rendzevous Onchip Pvt Ltd. Em : rohit@trinc.com
First Floor, Plot No 14
New Vasavi Nagar, Karkhana
Secunderbad -500019.
India
**************************************************************************
Follow-Ups:
References: