Subject: [anonsec] BYPASS OR PROTECT

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 28 Mar 2007 17:59:02 -0500

As you may recall, at last week's IETF 68 meeting I presented the
current state of the connection latching I-D.

One thing I had added to it was a description of "BYPASS OR PROTECT" --
a way to negotiate the use/non-use of IPsec for packet flows associated
with applications that are IPsec-aware and can handle the non-use of
IPsec through such means as using TLS/SASL/GSS-API/... for session
protection.

Sam commented that he thought that Stephen would object, but Stephen did
not make any objections at the meeting.  Instead Stephen explained that
his main concern is that nothing we do here be inconsistent with the
access controls of IPsec [RFC4301] -- essentially restating what the WG
charter says on this matter.

You may also recall that in the case of the core BTNS document the
access control issue had been about ensuring that BTNS peers not be
allowed to assert traffic selectors that non-BTNS peers are allowed to
assert.  And recall that we addressed this by providing that the PAD be
searched twice, once at authentication time and once at CHILD SA
creation time, the latter to find that the asserted traffic selectors do
not overlap with ones reserved for non-BTNS peers.

My question to Stephen and others: does BYPASS OR PROTECT as specified
in the current connection latching I-D fall foul of the RFC4301 access
control model?

My view is that no, it does not, though it is an extension of the SPD in
the RFC4301 model, and that it is needed to in order to support channel
binding applications.  Without BYPASS OR PROTECT we'll likely see
applications resort to using two port numbers: one for PROTECTed traffic
and one for BYPASSed traffic -- if connect() on the protected port fails
or times out try connect() on the bypassed port).  The two-port
alternative clearly does not fall foul of the RFC4301 access control
model; it follows that use of BYPASS OR PROTECT _for IPsec-aware
application port selectors_ does not either.

Stephen, Sam, others, care to comment?

Nico
--