[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multiple payloads via "ID_LIST"
If they needed it yesterday tell them to establish 2 SAs, one soley
for X and the other soley for Y. It would be *nice* to be able to have a
single one but I think this clearly falls in the "if it ain't broke..."
category. It can be easily solved today (and yesterday too) using existing
mechanisms.
Dan.
On Tue, 22 Sep 1998 18:57:48 PDT you wrote
> Michael C. Richardson wrote:
> >
> > Okay, but tell us the policy you are currently unable to express, which
> > you *need* to express *now*. (Ideally, have your customer tell us the polic
>y)
> >
>
> Here's an example from one of our customers:
>
> Z Y X W
> | | | |
> +=+ | | | | +=+
> |a|-| | | |-|d|
> +=+ | +===+ | +=====+ +=====+ | +===+ | +=+
> +-|RTR|-|--| SGW |------------| SGW |---|-|RTR|----|
> | +===+ | +=====+ +=====+ | +===+ |
> | | | |
> | | | |
> | +=+ | | +=+
> |b|-| |-|c|
> +=+ | | +=+
>
>
> Say Z and Y are subnets which can't be uniquely expressed together with
> a single bitmask, but which *can* be expressed with a range in the SPD.
> An example would be Z=10.3.0.0, Y=10.4.0.0, SPD source selector value =
> 10.3-4.0.0, however you choose to represent it. In this case, the subnet
> list is the only way to express both subnets in one payload, since there
> is no method for expressing such a range defined in the DOI. I guess an
> alternate solution to our proposals would be to try to come up with some
> way to express ranges and wildcards in the payload, but that seems even
> more complex...
>
> > I'm trying to do: "if it ain't broke don't fix it" here, so we can get
> > the time required to discuss a new payload and resolve whatever other issue
>s
> > that might need resolving for a 1.1 of ISAKMP.
> > (No, I don't want to push a 1.1 any time soon)
> >
> > I should also point out that you can implement something custom: the vend
>or
> > IDs and private payload space should provide for this. That way we'll
> > have some experience in the field before we write something down as a
> > standard.
>
> I agree, and we are in the process of implementing the vendor
> payload/private payload solution. As I said, I'm just trying to give
> this issue a shove to the front burner...
>
> Scott
References: