Re: SPD Syntax Example

[ravivsn@roc.co.in]

Hi,
  After some thinking, I also feel that providing kind of flexibility
  is good. It is really going to solve the problem
  of creating security tunnel between two sites, having multiple
  subnets, when combined with services.

  To support, this kind of flexibility, current TS is not good
  enough. Based on example given, 3000 Traffic Selectors need to
  be sent ( Did I get my math correct? ) which results to 40K of
  data in IKE message.

  I could think of two approaches.
  - Provide flexibility in TS, where IP address ranges represented
    independently from Port ranges.
  - TS payload carrying symbolic name

  I see that rfc2401bis talks about symbolic name and same can
  be sent in TS to facilitate this.

  I hope, IKEv2 can accommodate this.

Thanks
Ravi

----- Original Message -----
From: "Tero Kivinen" <kivinen@iki.fi>
To: "vamsi" <vamsi@intotoinc.com>
Cc: "Stephen Kent" <kent@bbn.com>; <ravivsn@roc.co.in>;
<ipsec@lists.tislabs.com>
Sent: Thursday, January 22, 2004 6:37 PM
Subject: Re: an SPD syntax example


> vamsi writes:
> >     I felt that original SPD syntax is good, which provides very good
> >     flexibility and ease of administering the policies in large
enterprise
> >     environments.
>
> The SPD format described in the RFC2401bis is going to be example SPD,
> which gives out the minimal requirements for the SPD to support.
> Implementations can implement any kind of compressed / optimized SPDs
> as long as they can express same thing that the minimalistic example
> SPD in the RFC2401bis can express.
>
> >     Consider that, there are 50 discrete subnets in an organization and
> >     the security needs to be applied for port 25, port 80 and port 110.
> >     With the original approach (ASN1), proposed by Steve, it only
requires
> >     configuration of 50 ranges of IP addresses, 3 ranges of Ports and
> >     put them in one Selector list.
>
> So implement it as subnets and compressed source and destination
> addresses. You can still "convert" that to the basic format meaning,
> that anyone from the outside cannot really see which format you are
> using.
>
> > If we go with this approach, some changes to 'Traffic Selector' in IKEv2
> > are required.
> > It means that, each traffic Selector should be able to accommodate
> >         Number of IP address ranges
> >         <all IP address ranges>
> >          Protocol
> >          Number of Port ranges
> >          <all Port ranges>
>
> No. I think it is way too late to make that kind of changes to IKEv2,
> and also I think the current format is so much simplier and easier to
> parse, that we can live with the few extra bytes for that kind of
> cases.
> --