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

[no subject]

(firewall-user@xxxxxxxxxxxxxxxxxxxx [])
	by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id CAA14855
	Tue, 30 Sep 2003 02:26:51 -0400 (EDT)
Message-Id: <>
X-Sender: ravivsn@xxxxxxxxxxxxx
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 30 Sep 2003 12:16:15 +0530
To: Stephen Kent <kent@xxxxxxx>, ipsec@xxxxxxxxxxxxxxxxx
From: Ravi Kumar <ravivsn@xxxxxxxxx>
Subject: Re: SPD issues
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: owner-ipsec@xxxxxxxxxxxxxxxxx
Precedence: bulk

Hi Steve,
        In a typical CPE gateways, one SPD is good enough. But in
        PPVPN (MTU/MDU or ISP markets) context, one SPD per
       subscriber is needed. Again, the subscriber can't be associated
       with interface. It is possible that subscribe can have more than one
       interface associated with him/her. Also, the selection of SPD may not
      even depend on interface. It can be based on VLAN ID or MPLS Label.

      Due to this, I vote  your conclusion statement (with one exception).
           Keep the multiple SPD concept. Keep the SPD selection to
           the implementations.

At 06:50 PM 9/24/03 -0400, Stephen Kent wrote:
>In revising the processing mode, based on feedback from various folks, I
>want to make sure that we have enough functionality, but not more than is
>really needed. In this regard, I want to conduct a quick poll.
>The topic, in a way, is how many SPDs do we need?  2401 says we have an
>SPD per interface, but maybe that's not enough, or too many, or just not
>the right question to be asking.
>So, let's ask the question differently.  What are the inputs needed to
>select the right SPD?
>          - In a very simple context it seems we could get away with just
>  one SPD, relative to which all traffic is examined.  so any answer we
>  choose must yield this answer for the simple cases.
>          - In a PPVPN context, having a different SPD per subscriber seems
>  to make sense, since the intent it so allow each subscriber to define
>  his/her own SPD.  In this case, the SPD could be selected based on the
>  source of the (outbound) traffic. You could think of this as being per
>  interface, relative to the interfaces via which the outbound traffic
>  arrives, but it does not imply a need for different SPDs for the
>  interfaces via which inbound traffic arrives, an asymmetry.
>          - My previous proposal for a revised processing model, from a few
>  weeks ago, retained the idea of multiple SPDs, allocating them to virtual
>  interfaces, and introduced the notion of a forwarding function to select
>  the right virtual interface, and thus SPD.  But, unless we feel a need to
>  have different SPDs per interface, this seems like overkill. I think we
>  do want to allow forwarding of outbound traffic to be independent of SPD
>  selection, so some notion of an explicit forwarding function in the model
>  still seems appropriate. but, as we discussed the model, there was a
>  suggestion that we might need two such functions, one to select an SPD,
>  and then one to be applied after IPsec processing. maybe, if we separate
>  SPD selection from interface selection we can have two functions but only
>  one of them is really for forwarding.
>          - Along those lines, we could introduce an SPD selector function
>  that, like the forwarding function, can use any info in a packet to
>  select an SPD, but without associating the SPD with an interface per se.

The Views Presented in this mail are completely mine. The company is not
responsible for what so ever.

Ravi Kumar CH
Rendezvous On Chip (I) Pvt Ltd
Hyderabad, INDIA