Re: [IPsec] [saag] IETF 114 IPsecME report

Valery Smyslov <smyslov.ietf@gmail.com> Tue, 31 January 2023 14:02 UTC

From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Paul Wouters' <paul@nohats.ca>
Cc: 'Tero Kivinen' <kivinen@iki.fi>, 'Paul Wouters' <paul.wouters@aiven.io>, ipsec@ietf.org, 'Yoav Nir' <ynir.ietf@gmail.com>, 'Roman Danyliw' <rdd@cert.org>
References: <25311.20490.971667.883557@fireball.acr.fi> <CAGL5yWbWUvqPPsC3e-rqEc5i00WWXAhe=_SurmiWDNzfF54rRg@mail.gmail.com> <CAGL5yWbpx2K3X7FpMVASUeTzQZ2A=tKDw9s5UBqWUKbGnTgxiw@mail.gmail.com> <25558.47779.655532.512440@fireball.acr.fi> <016301d93576$bb63c030$322b4090$@gmail.com> <b3438e48-84b0-d8bc-b9ef-b0b3ae00794c@nohats.ca>
In-Reply-To: <b3438e48-84b0-d8bc-b9ef-b0b3ae00794c@nohats.ca>
Date: Tue, 31 Jan 2023 17:02:29 +0300
Message-ID: <016f01d9357c$a86ec9b0$f94c5d10$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQIgvL5PIvTMn4bG60OyNKXMODbfRQLH29ciAg85jPgCEOUVAgJRWqnwAjWrufGtzgXdwA==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/ujfBXVEgy0kvAzsDRIBKRYSrfgs>
Subject: Re: [IPsec] [saag] IETF 114 IPsecME report
Precedence: list

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

Re: [IPsec] [saag] IETF 114 IPsecME report Tero Kivinen
Re: [IPsec] [saag] IETF 114 IPsecME report Valery Smyslov
Re: [IPsec] [saag] IETF 114 IPsecME report Paul Wouters
Re: [IPsec] [saag] IETF 114 IPsecME report Valery Smyslov
Re: [IPsec] [saag] IETF 114 IPsecME report Tero Kivinen
Re: [IPsec] [saag] IETF 114 IPsecME report Paul Wouters