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

Re: multiple payloads via "ID_LIST"



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 policy)
> 

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 issues
> 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 vendor
> 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


Follow-Ups: References: