Hi Paul,
> > The "proper" way would be to introduce new TS types
> > TS_IPV4_ADDR_RANGE_WITH_SECLABEL and TS_IPV6_ADDR_RANGE_WITH_SECLABEL.
> > I recall that it was already tried before, but I don't remember
> > why this way was abandoned.
>
> The fear of combinatory explosion if something else got added. Eg lets
> say we have a similar new TS TYPE that modifies like sec_label. Let's
> call it FOO. We would end up with:
>
> TS_IPV4_ADDR_RANGE
> TS_IPV4_ADDR_RANGE_WITH_SECLABEL
> TS_IPV4_ADDR_RANGE_WITH_FOO
> TS_IPV4_ADDR_RANGE_WITH_SECLABEL_AND_FOO
> TS_IPV6_ADDR_RANGE
> TS_IPV4_ADDR_RANGE_WITH_FOO
> TS_IPV6_ADDR_RANGE_WITH_SECLABEL
> TS_IPV6_ADDR_RANGE_WITH_SECLABEL_AND_FOO
>
> The WG thought this would be a worse solution.
This could be solved by adding only two new TS types
TS_IPV4_ADDR_RANGE_WITH_CONSTRAINTS and TS_IPV6_ADDR_RANGE_WITH_CONSTRAINTS
with a format that allows to add new constraints to the Traffic Selector.
Something like:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type |IP Protocol ID*| Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port* | End Port* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Starting Address* ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ending Address* ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Constraints* ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each constraint can be represented as an Attribute
(it is also possible to introduce a dedicated structure) and all of them are
treated with AND.
This way we may add any number of additional restrictions
to the base Traffic Selector.
Regards,
Valery.
>
> Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
