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

    RE: IPsec Usage Question

    >>>>> "BlackG" == Black David <> writes:
     BlackG> AFAIK, IPsec has no standard or widely deployed mechanism for
     BlackG> handling gateway discovery or address association
     BlackG> dynamically.
    But let's consider a very common IPsec deployment scenario.  I think
    this is actually the predominant one, but let's not argue about that;
    it certainly is quite common.
    Scenario: two sites, each with an IPsec gateway, and an IPsec tunnel
    set up between the two sites.  All traffic between the two sites goes
    through the tunnel.  (This is the classic IPsec based VPN scenario.)
    The way this is handled is simply by configuring the routing tables on
    the two IPsec gateways to forward to the other site through the
    tunnel.  As far as the other nodes on the two sites is concerned, the
    other site is simply reachable via ordinary IP mechanisms, and the
    existence of the tunnel, or the addresses used in the outer headers,
    are none of its concern.  And of course the IP addresses of the inner
    header cannot possibly equal those of the outer header in this
    This example MUST work.  So you cannot require inner == outer
    address, because that translates into saying that IP Storage cannot be
    protected by a site to site IPsec tunnel.
    Now for a different case: if you use tunnel mode to protect traffic
    for a single node (a common case for laptops, so this is often called
    the "road warrior" case) then it may well be useful to allow inner ==
    outer.  Some road warrior OS types will want that, others don't care
    so much, so it can be a simplifying approach.  I have no objection at
    all to saying that inner == outer is useful, and for that matter I can
    go along with saying inner == outer should be supported.  But, either
    way, inner != outer must be supported.


Last updated: Mon Feb 04 20:17:55 2002
8628 messages in chronological order