RE: Traffic Selectors (was SA fragments)

[Stephen Kent <kent@bbn.com>]

At 23:24 -0800 2/20/04, Bora Akyol wrote:
>Since these documents are about to go to Last Call
>(and I have been there before), this will be my last email
>on this subject.
>The thread is not productive other than raising my blood pressure :-)
>
>And finally my apologies to the WG and Steve Kent specifically for
>dragging on this
>thread longer than it needed to be and not engaging in the conversation
>3 years ago.
>
>However, I would love to hear private/public opinions to the
>semi-coherent
>thought train that I wrote below:
>
>----------------
>
>How come I have not seen IPSEC policy specified
>that contains TCP/UDP port selectors in reports from
>the field?

I cannot account for what you have or have not seen.

>Then I realized, when I use an SSL enabled POP client
>to get my email, I am in fact using transport layer security
>with TCP port numbers.
>When I check my bank account balance, there again, SSL.

Presumably you are trying to argue that if one wants port level 
security, the one uses SSL, but SSL does NOT provide any built, in 
access controls, so this is an odd comparison.

>So answering Nicolas's question about multi-user trusted OS,
>if I am an application developer and I have the SSL API available
>to me, why do I trust the network layer to provide me
>with the security? I don't, I use SSL or transport layer security.
>One could also argue that this makes the application more robust
>since it is not dependent on a lower layer for security.

there is considerable literature on the differences between SSL and 
IPsec security features, which suggests that there are good reasons 
for choosing each in different contexts. however, the argument that 
port level security is better provided by SSL is NOT part of that 
literature.

>If IP is the network layer, and IPSEC is a network layer
>protocol, why does a network layer security protocol
>care about transport layer traffic selectors?

IPsec is a security protocol that operates at the Ip layer.  It is 
NOT just an encryption, authentication, integrity protocol. Access 
control is an important feature of IPsec, as the 2401bis intro notes. 
IPsec offers access controls consistent with what a stateless, packet 
filtering firewall offers. this includes port level filtering.  the 
lack of stateful inspection is less of a concern here, because SAs 
are authenticated, and thus we know who/what is at the other end.

>Is the inclusion
>of transport layer traffic selectors (TCP/UDP ports)
>an optimization in the
>original design? Or
>is it now an redundant feature with the pervasive
>deployment of SSL/TLS?

badly worded question.  why not just ask if Ipsec has stooped beating 
its virtual wife?

>Would application developers actually
>ever trust the network layer to provide them with the security that
>they need? How can an application trust the network administrator
>(especially in a shared system)
>to correctly configure security on a per transport layer demux
>port basis especially when money or financial information
>is involved? That is, unless everyone is sharing the same security
>policy in which case the port-based selectors are not needed.

a narrowly focused question, since IPsec is implemented in multiple 
contexts, not all of which are available to application developers, 
even when IPsec is in a host, e.g., consider the NIC implementations 
of IPsec which are designed to be managed centrally, not by app 
developers.

>If all one wants to do is secure a particular application running
>over a specific but not pre-determined port (dynamic), then is the
>transport layer security the easier way to go?
>
>Only time and deployment
>experience will tell the rest of the story in terms of what
>features get used or are left to die. However, if the recent
>uptake in SSL-VPNs (search google/light reading for market predictions)
>is an indication, we have interesting times ahead.

This WG would be ill-advised to make standards design decisions based 
on what trade rags say.

Steve