Subject: Re: SPD Syntax Example

From: [email-masked]
Date: Sat, 24 Jan 2004 06:51:13 +0530 (IST)

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" <[email-masked]>
To: "vamsi" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>; <[email-masked]>;
<[email-masked]>
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.
> --

---

From: Andrew Krywaniuk <[email-masked]>
Date: Sun, 25 Jan 2004 02:08:19 -0500 (EST)

>   be sent ( Did I get my math correct? ) which

A more relevant question might be why we need to have
this complicated selector negotiation at all. We could
save ourselves a lot of hassle by just letting each
party enforce their own policy at the firewall level.
This is an issue that was brought up on this list a
long time ago, and it's a shame that it didn't get
included in the IPsec/IKE redesign process.

As I remember it, the justification for this design
was that the SADB and the firewall might be located on
different physical devices. But come on... Raise your
hand if you are deploying an IPsec implementation that
is not integrated with a firewall. So the question is
why are we optimizing for the edge case, while
complicating the configuration of the average case.

-a

=====
Andrew Krywaniuk, Fortinet Technologies
Please *do not* reply to this address. (I will not read it)
Reply to askrywan..hotmail..com or my home address.

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Jan 2004 09:22:06 -0500

Andrew,

We've had this discussion before, and I'd rather not revisit it.  If 
peers do not negotiate the selectors for an SA, interoperability 
problems arise.  We have experience with this happening today, 
because IKE v1 did not do as well as IKE v2 in this regard. For 
example, in IKE v2 the initiator sends the packet header info for the 
packet that triggers SA creation, to allow the responder more 
flexibility in finding a suitable SPD entry when peers have 
overlapping but not identical SPD entries.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Jan 2004 09:53:43 -0500

>   I hope, IKEv2 can accommodate this.

Ravi,

Symbolc names are not sent in payloads.  Their use of very 
restricted.  We'll be explaining more about this in  an upcoming 
2401bis revision message.

I don't recall the example in detail, but it seems unlikely that, in 
practice. one would need to send such a big TS payload. We have 
ranges for addresses and one can express any subnet via a range, so 
the suggestion to add subnets as a separate type of selector 
specification adds no new functionality.

And, as others have mentioned, we're too far along in the process to 
make a change of the sort suggested.

Steve