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

Re: Selection of proposals (fwd)



Hi,
can somebody guide me here, 

 consider the case4 (in Page 27) from H2
  +==================================================+
  |                                                  |
  | +========================+                       | 
  | |                        |                       |
  | |                        |                       |  
  H1* ---- (Internet) ------|SG2* ---- (Local ----- H2*|
   .

 H1 must have TWO individual IN-BOUND policies H2-SG2 and H2-H1.

And let's assume that SAs are there. Since these two are indivi-
dual policies I assume that there are TWO inbound SAs linked to
diffrent SPD entries. 


Then in that case when a packet arrive at H1 from H2 which has
Two SAs applied to it ONE @H2 and OTHER ONE @ SG2, if you 
apply the IpSec processing according to the Steps 1,2,3 and 4
specified on Page-35 in Sec-5.2.1 until Step2 there will be
no problem. And at the end of the 2nd step we will have list
of SAs applied.
 
But finding an incoming policy (step3 & 4) fails
here bcoz there is no single SPD entry matches the list of SAs
we collected.

otherwise, how will be the Inbound policy at H1 in this case?
 How will check the policy here? 

-thanks
-ramana

On Thu, 5 Nov 1998, Stephen Kent wrote:

> Ramana,
> 
> >In Sec4.3 Combining Security Associations(page 12) describes
> >how we can bundle SAs.
> > 1)Transport adjacency
> > 2)Iterated tunneling
> >
> >And this example matches case2 (in Page 13). so now can I
> >say that this is a valid cinfiguration with reference to
> >draft.
> 
> Example 2 in 4.3 shows a host with two iterated tunnels, one to a gateway,
> and the other to a host.  The example that triggered this message exchange
> shows a gateway as the common endpoint for the two tunnels. So the two are
> not exactly the same. However, I agree that the general case described in
> 4.3 should encompass Rohit's example, as it is one in which one of the two
> tunnel endpoints is the same.  However, Section 4.5 is the authoritative
> section describing what one MUST support.  Section 4.3 refers to 4.5.  In
> 4.5, there is no hard requirement to support iterated tunnels with a common
> endpoint.
> 
> >otherwise, what's wrong with that configuration. Can we
> >know why the implementors requested it that way?
> 
> Iteration of tunnels adds considerable complexity to processing. There
> appeared to be no substantive security benefit from such nesting in the
> cases of primary interest, where a host formed one end of the tunnel.  Note
> that we do require support for the combination of one tunnel and one
> transport SA involving a host, and that was deemed adequate.  However, if
> one wants to have iterated SAs with a gateway as the endpoint, then tunnel
> mode is required for both SAs.  So, the WG needs to decide if this
> configuration is one that merits support.  If so, we should add it to the
> list of mandatory configurations, to ensure support.
> 
> Steve
> 
>
Follow-Ups: