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

    RE: IPsec Usage Question

    >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.
    This is not Kansas any more... The iSCSI devices on both sites (assuming
    that's their only IPsec protection) are not iSCSI compliant. This
    doesn't cover the IPsec protection mandated by iSCSI.
    Ofer Biran
    Storage and Systems Technology
    IBM Research Lab in Haifa  972-4-8296253
    Paul Koning <> on 05/02/2002 00:17:54
    Sent by:
    Subject:  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: Tue Feb 05 12:17:58 2002
8638 messages in chronological order