Subject: Issue #76: TFC padding in ESPv3 and requirments for IKEv2

From: "Theodore Ts'o" <[email-masked]>
Date: Sat, 31 Jan 2004 23:58:56 -0500

While looking over the remaining issues still open on RFC 2401bis,
Barbara and I were looking at issue #76, to make sure it was fully
addressed.  Per the discussion on the mailing list, this issue was
transferred to the ESP v3 document.  So when I went to double check to
make sure the text was properly reflected in ESPv3, I found the
following text:

   TFC padding takes advantage of an intrinsic feature of IP, i.e.,
   other data may be present in a buffer delivered to an IP interface,
   beyond the packet length indicated by the IP total length field.
   Thus, in tunnel mode, a compliant IP stack at a receiver should
   ignore this padding. In this sense, existing IPsec implementations
   could have made use of this capability previously, in a transparent
   fashion. However, because receivers may not have been prepared to
   deal with this padding, the SA management protocol MUST negotiate
   this service prior to a transmitter employing it, to ensure backward
   compatibility.  Combined with the convention described in section 2.6
   above, about the use of protocol ID 59, an ESP implementation is
   capable of generating dummy and real packets that exhibit much
   greater length variability, in support of TFC.

There's only one minor problem.  IKEv2 doesn't currently have a way of
negotiating this capability, and the ESPv3 specification states that the
SA management protocol MUST negotiate this facility.  This leaves us
with a couple of possibilities:

1) We go ahead with the documents ESPv3 and IKEv2 as they currently
stand, which would mean that TFC padding cannot be used until somoene
writes a quick RFC which defines a new notification message:

        ESP_TFC_PADDING_SUPPORTED                   16394

            This notification asserts that the sending endpoint will
	    accept packets that contain Flow Confidetiality (TFC)
	    padding.

2) We modify IKEv2 to include this new notification message now.

3) We modify ESPv3 to indicate that the mere use of IKEv2 implies that
   the receiver can accept ESP packets that contain RFC padding.

What do folks think?

						- Ted

---

From: Jean-Jacques Puig <[email-masked]>
Date: Mon, 2 Feb 2004 12:14:27 +0100

On Sat, Jan 31, 2004 at 11:58:56PM -0500, Theodore Ts'o wrote:
> 
> ... in ESPv3, I found the
> following text:
> 

Either ways are correct, however I think 2) is the most reasonable
solution, given documents involved are still IDs. I'd rather see some
more lines in IKEv2 than an almost empty RFC.

>    the receiver can accept ESP packets that contain RFC padding.
                                                      ^- Nice lapsus :)
I don't see 3) as an alternative to specifying the notification message
somewhere; do you mean that the requirement for the SA-MP to negotiate
TFC should be eased for IKEv2 ? I think this should always be
negotiated, not only because of backward compatibility, but also because
of possible performance issues wrt link capacity and host memory: one
should be able to tell it's peer it can not live easily with padded or
dummy packets.

-- 
Jean-Jacques Puig

[homepage] http://www-lor.int-evry.fr/~puig/

---

From: Charles Lynn <[email-masked]>
Date: Mon, 2 Feb 2004 12:19:59 -0500 (EST)

Catching up...
A few comments on the ongoing SPD syntax discussion, IKE, and 2401bis.

>It is better to make this as close to IKEv2 Traffic Selector as
>possible.

I disagree :-) ... on the grounds that clarity and simplicity for the
administrators promote better security.

I think that the syntax should be designed to encourage a clear and
concise specification of the types of traffic that should be protected.
We should not be using a syntax that lets an administrator enter
information that is non-sensical or inappropriate, as much as possible.
The "software" can translate that format into whatever the key management
protocol(s) use internally; the programmer only has to get the translation
right once, the admin would have to do it for each SelectorSet.

As an example, the IKEv2 syntax (which is an improvement over IKEv1,
and which I do not think needs to be changed -- but does need to be
"clarified") allows one protocol to be specified in the initiator
traffic selectors and a totally different one to be specified in the
responder traffic selectors -- something that is clearly wrong.

So I would suggest that the SelectorSet syntax specify local and
remote addresses, which can be a list of single addresses, prefixes
(subnets), or ranges; a protocol or list of protocols; and for each
protocol any additional information -- ports (a list of single values
or ranges), ICMP Type and Code (a list of Types and for each Type a
list of Codes or ranges of Codes), MH Type or ranges of Types, etc.
The translator gets to do the cross-product when translating to the
IKEv2 format, the admin does not have to do it; keeping the policy
the the admin has to look at smaller - an entry can be seen all at
once - makes things clearer, and more apt to express the admin's intent.

There also seems to be possible confusion with the terms "source"/
"destination", "initiator"/"responder", etc.  The first pair is
tied to packets, the second to roles or the peers in the IKE.
One might interpret the latter pair to imply restrictions on which
end can "initiate" a TCP connection (the SYN without ACK) semantic.
Are we saying that there should be one SPD entry to protect TCP
connections that A initiates to B and a second one for traffic that
B initiates to A?  Note that this is distinction is muddied by the
fact that most current TCP applications use well-known ports in a
client-server model; specification of ports is currently overloaded
with directionality.  TCP is really peer-to-peer; it would be
unfortunate, in my opinion, if the IKE syntax were to encourage
administrators to block emerging services because they cannot
specify the policy that they want.  It is the old chicken and egg
problem -- new apps cannot be deployed because of artificial limitations
elsewhere, and since they cannot be deployed, there is no "user demand"
for them.  I would suggest using "local"/"remote" or some such terms.
The current syntax does not really bind "sourceAddr" or "destAddr" to
"inbound" or "outbound".

Example: could "insiders" circumvent an admin's policy by initiating
a TCP connection *from* port 20 *to* a remote port 4567 (many folks
are "admins" on their desktop systems)?  I think that removing the
"inbound" and "outbound" tags for two-way flows opens up this hole.

As I just mentioned in my message "IKEv2 changes", I think that there
should be text describing how unidirectional policies should be
encoded in the current syntax. I would suggest saying that the ICMP
sender's end should specify the Type and Code in the "initiator's"
traffic selectors, and that they should be "OPAGUE" in the
"responder's".  It should be part of the ASN.1 syntax for ICMP Type
and Code, and Mobility Header Type.

I would add ANY and OPAQUE to the 2401bis syntax as CHOICEs.  2401bis
is the architecture document, intended for administrators as well as
implementors, so I think adding text that exemplifies things of
interest to the admins is beneficial.  (Please respond re: ASN.1 being
easy for folks to understand to /dev/null :-)  The standard conformance
test is any implementation that exhibits the external behavior, so
there is no requirement that an implementation have a one-for-one
mapping.

I would make protocol a list, as that is how admins think of it;
again, let the software do the cross-products, not the admin.

> Note, that in most cases the code 0 is reserved,
> thus it cannot be used as special ANY value.

Actually, it is the cases where it is not "reserverd" that cause the
problem, i.e., protocol 0 is the Hop-by-Hop extension header.

If one defines ANY as a *range* whose "start" value is 0 and whose
"end" value is 2^^n-1, then the range 0..0 should be distinguishable
from ANY.  Protocol is the problem, as IKEv2 does not allow it to be a
range.  I can see wanting to indicate fragments for any protocol, but
then the Fragment Header is the "protocol" and ANY would be the
protocol specific additional information (aka IKEv2 ports) which
allows a range. That still leaves how to express the policy "all
traffic between A and B".  One could use the (currently) reserved
value of 255, or request that IANA assign a value to get around
IKEv2's syntactical limitation.  <CrockAlert> Note that protocol 61 is
assigned to any host internal protocol, which should never (FLW) be
sent between hosts, so it might be possible to overload
it. </CrockAlert>

Re: combinatorial explosion:
> I don't recall the example in detail, but it seems unlikely that, in 
> practice. one would need to send such a big TS payload.

The conclusion seems to be saying that the admin can work around the
problem by creating multiple SAs that protect subsets of the desired
traffic.  If a policy is to be applied to many types of traffic,
having to use multiple policies, which as currently defined, implies
multiple SAs, does not seem like a good idea from the policy
management perspective.  Then there is TFC - using multiple SAs
instead of one decreases the level of TFC that one can achieve.

Comments?

Charlie

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Feb 2004 09:49:10 -0500

Ted,

When I last spoke with Russ, he indicated that he was prepared to 
tolerate another delay on the IKE v2 document to incorporate the 
change that Hugo suggested, to incorporate bits from an key-based EAP 
method into the PRF for the keys used for encryption & integrity.  IF 
he still feels this way, then I'd suggest suggestion #2, i.e., modify 
IKE now to add the necessary notification message.

Steve

---

From: Charles Lynn <[email-masked]>
Date: Mon, 2 Feb 2004 12:05:20 -0500 (EST)

> tolerate another delay on the IKE v2 document to incorporate ...
> IF he still feels this way, then ...

There are a few other items, most of which have been mentioned at one
time or another, that I think need to be incorporated into the IKEv2 doc.

Please add text saying how the ICMP Type and Code are encoded into the
16-bit "port" field -- Type in the the most significant 8 bits and
Code in the least significant 8 bits; and text saying that the
Mobility Header Type should be in the most significant 8 bits and the
least significant 8 bits should be 0 for the "start" field of the
range and 255 for the "end" field).

Please add text saying that OPAQUE is encoded by setting a "start"
field to the maximum value and the "end" field to the minimum value.

I think that there should be text describing how unidirectional
policies should be encoded in the current syntax.  The immediate
examples are ICMP and the Mobility Header. I would suggest saying that
the ICMP sender's end should specify the Type and Code in the
"initiator's" traffic selectors, and that they should be "OPAGUE" in
the "responder's".

I think that the 2401bis model is for non-initial fragments to be
placed into a "fragment-only" SA.  If so, please add text to IKEv2
saying that IPv4 non-initial fragments should be mapped to protocol 44
(IPv6 Fragmentation Header).

If we will be supporting SAs for non-initial fragments at the level of
protocol, e.g., TCP fragments get a different SA than UDP fragments,
then the fragmentation "protocol" would need to have "ports" that is
the value of the IPv4 protocol field or IPv6 Fragmentation Header's
Next Header field.  The 8-bit protcol number should be encoded right
justivfied in the port field (i.e., the most significant 8 bits should
be zero). If the WG thinks that this is reasonable, then the IKEv2
and/or 2401bis should describe it.

Charlie

---

From: Stephen Kent <[email-masked]>
Date: Mon, 2 Feb 2004 14:22:10 -0500

>administrators promote better security.

Good point; clarity is better, so long as it is easily mapped to 
IKEv2 TS payloads.

>right once, the admin would have to do it for each SelectorSet.

yes, but let's keep the translation easy, or it will be done improperly.

>responder traffic selectors -- something that is clearly wrong.

agreed. good example.

Firewalls distinguish between connection initiators and responders, 
but that may not be critical here, since that we have authentication 
for SA establishment, and integrity mechanism for continuous 
protection after SA establishment. So, for SAs the asymmetry may not 
be an issue.  Note that the current syntax I suggested does retain 
inbound vs. outbound distinctions for non-IPsec traffic, where we 
lack the protections noted above.

Let me suggest that you prepare an ASN.1 syntax example that meets 
the criteria you described in your message and bring it to the list, 
along with the explanation of how to map it to IKE TS payloads. We 
can work from there.

Steve