[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re:
I am restating the problem, however the scenerio specified here is that
given in "draft-ietf-ipsec-arch-sec-06.txt" draft on PAGE 27 case 4:
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server
Let us assume that N1 is the IP network address for the network of H1 and
N2 that of the network comprising SG2 and H2.
The policy at H1 for outbound is
direction = out
Selectors :
src addr H1
dest addr H2
Security Policy :
Security Gateway SG2
Protocol ESP with Auth
Mode Tunnel
Algorithms 3DES or DES
MD5
Protocol AH (upto H2)
Mode Transport
Algorithms SHA-1 or MD5
OR
Security Gateway SG2
Protocol ESP with no authentication
Mode Tunnel
Algorithms 3DES
Protocol AH ESP (upto H2)
Mode Transport
Algorithms SHA-1
DES
(We think that this is the way the SPD entry will be and that there arent
individual entries for SG2 and H2! If they are two different entries in the
SPD, the inbound processing will accumulate an SA bundle that consists of
more than one protocol at H1 and finds that the individual SPD entries
cannot be satisfied by this.)
For inbound the same applies except that the selectors source and
destination addresses get interchanged.
The inbound policy at SG2 is :
direction = in
Selectors :
src addr H1
destaddr N2
Security Policy :
Protocol ESP with no auth
Mode Tunnel
Algorithms 3DES
(NOTE : dest here can be N2 or specifically H2)
For outbound the same applies except that the selectors source and
destination addresses get interchanged.
The policy at H2 for inbound is
Selectors :
src addr H1
destaddr H2
Security Policy :
Protocol AH
Mode Transport
Algorithms SHA-1
Protocol AH ESP
Mode Transport
Algorithms SHA-1
DES
For outbound the same applies except that the selectors source and
destination addresses get interchanged.
The questions we have are as follows :
* Is it possible for the negotiations with SG2 and H2 from H1 to happen
simultaneously or is it always mandatory that the ISAKMP traffic to H2 be
protected by the ESP tunnel from H1 to SG2?
* In the example policy above, since the negotiations with SG2 and H2
happen independently, SG2 selects the second choice offered by H1 and H2
selects the first one. Since these together satisfy neither of the security
policies mandated by H1, they cannot really form an SA bundle but are
perfect choices as far as IKE is concerned. The problem here is that we
treat the negotiations as completely independent and the selected protocols
and transforms are one of those offered. However, since both of them
together have to be applied to satisfy security requirements in H1, they
cannot form an SA bundle.
- Rohit
At , you wrote:
>At 05:29 PM 11/5/98 -0500, you wrote:
>>Rohit,
>>
>>I have to admit that I cannot follow the example, to understand what was
>>desired vs. what was negotiated and what the problem was. There are too
>>many indefinate atencedents in the text. Please restate the problem in the
>>following terms:
>>
>> Relevant outbound SPD entries for SG1. The entries should be
>>described in terms of selectors, required protocols, and algorithms. (The
>>term "proposal" does not relate to an SPD entry, it's an IKE term, so I
>>can't figure out what you're referring to.)
>>
>> Relevant inbound SPD entries for SG2 and H2, as above.
>>
>> IKE proposals sent by SG1 to SG2, and the response from SG2. Then,
>>with that SA in place, IKE proposals sent by SG1 to H2, and H2's response.
>>Then the resulting pair of iterated tunnels, and why this result does not
>>match what SG2's SPD called for.
>>
>>Steve
>>
>>