[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: