[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 traffic selector subsetting.
><snio>
>
>> >Port-constrained SAs make sense in the case of a multi-user
>> UNIX machine
>> >where the phase 1 id associated with port FOO is not
>> necessarily the same as
>> >the id on port BAR. Port-constrained selectors are NOT the
>> best mechanism
>> >for implementing packet filtering. In the vast majority of
>> VPN scenarios, a
>> >list of subnets would be appropriate for expressing phase 2
>> selectors.
>>
>> I disagree. Port filtering is appropriate in IPsec for the same
>> reasons it is appropriate in a firewall, i.e., a reasonable security
>> policy may wish to constrain traffic from a specified source to a
>> specific destination relative to a set of services offered by the
>> destination. So, for example, I may wish to bypass traffic from any
>> outside source directed to my SMTP server, but I want all such
>> traffic to be SMTP traffic, to reduce the likelihood that the server
>> can be attacked by external sources sending other types of traffic.
>
>I don't disagree that port filtering is appropriate; I just disagree with
>your model. I think it's an SA to a specific destination with a
>port-constrained policy. One implementation of this model could be an SA
>with a back-reference to a decorrelated SPD entry. Another is a
>topology-aware IPsec layer with a completely separate firewalling module.
>
Andrew,
I don't know what the phrase "topology-aware IPsec layer" means, so
I'm not sure what you are proposing.
We have maintained that the SA binding for a packet must be
maintained to ensure that the firewall-style rule checks are applied
to packets in the context of the SAs with which the rules are
associated.
Steve
Follow-Ups:
References: