[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Selection of proposals
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:
References: