Subject: 2401bis issues

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 14 Oct 2003 12:32:31 -0400

Here's the status of current 2401bis issues, and the resolution for a few of
them:

Rejected Issue 40 ("Interface SPD selector vs. per-interface SPD")
Rationale: This seems like an implementation issue, which won't affect
           interoperability.

Issues 44 ("forwarding table lookup to select virtual interface ID") and
       45 ("use of cache with de-correlated SPD")
are still open, waiting for 2401bis draft.

Rejected issue 67 ("IPsec management traffic")
Rationale: Implementation issue; we may want to add a paragraph describing the
           kinds of traffic an implementation may want to make sure are not
           affected by the SPD (e.g., IPv6 neighbor discovery, IKE), as a
           note to implementors.

Issue 68: see follow-on email

Rejected Issue 69 ("Multiple protocols per SPD entry")
Rationale: This is covered by
           issue 47 ("all selectors can be a list of ranges, per IKEv2 spec").

Accepted issue 74 ("inbound SA lookup -- multicast & unicast")

Issue 81 ("Handling outbound red fragments"): marked as possible reject
Rationale: since we decided not to adopt issue 49 ("red-side fragmentation
           option"), it doesn't make much sense to treat red fragments in this
           way. Yell if you disagree.

Issues 82 ("Creation of SAs - clarifications")
       85 ("DROP'd inbound packet - does not match SA")
 need more discussion; our feeling for 85 is that it would be best done through
 an IKE notification.

Accepted issue 86 ("Add IPv6 mobility header message type as selector")

Issue 87 ("Permit SGs to use transport mode when they are the endpoints of the communication") will likely be accepted.

-Angelos

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Oct 2003 13:28:32 -0400

>Rationale: This seems like an implementation issue, which won't affect

I agree that this is not an interoperability issue, but 2401 
established a per-interface SPD requirement and I think we now have 
heard from various folks that this is unduly restrictive. So as part 
of the revised processing model
we need to remove the old, 2401 restriction and explain what the new 
model does and why.

>are still open, waiting for 2401bis draft.

this will also be covered i the revised model.

>            affected by the SPD (e.g., IPv6 neighbor discovery, IKE), as a

OK.

>            issue 47 ("all selectors can be a list of ranges, per IKEv2 spec").

Tero has pointed out in some private e-mail that this 
characterization in quotes is not quite right, i.e., IKEv2 does not 
work this way!  So, we are revising the characterization accordingly. 
The bottom line is that one can accommodate multiple protocols in a 
single SPD entry, because the entry really consists of a list of 
selector sets, each set contains S/D IP address range, ONE protocol 
(or ANY), and S/D port range.  The "list of ranges" effect is 
achieved in that fashion.

>Issue 87 ("Permit SGs to use transport mode when they are the 
>endpoints of the communication") will likely be accepted.

Yes, as refined in the message exchange with Joe over the last 24 hours.

Steve

---

From: "Angelos D. Keromytis" <[email-masked]>
Date: Tue, 14 Oct 2003 14:00:36 -0400

>we need to remove the old, 2401 restriction and explain what the new 

I agree on removing the limitation.

>achieved in that fashion.

Correct.
-Angelos

---

From: Mark Duffy <[email-masked]>
Date: Tue, 14 Oct 2003 16:26:18 -0400

>            way. Yell if you disagree.

Does this mean that having 2401bis permit red-side fragmentation is 
rejected, or just that the special treatment that was proposed for the 
fragments (separate SAs for them) is rejected?

 From where I sit, allowing red-side fragmentation is very important.

Thanks, Mark

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Oct 2003 12:29:51 +0300

Stephen Kent writes:
> heard from various folks that this is unduly restrictive. 

The processing model in RFC2401 is just one example way how to do it,
and as RFC2401 says, you can implement IPsec processing in a way you
like, as long as it looks from the outside that it is similar than
what is described in the RFC2401. If we cannot see the difference of
those two ways, I do not think we need to change it. Implementators
who want to implement it that way can already do it, I do not think
RFC2401 restricts anybody in that way.

----------------------------------------------------------------------
4.4 Security Association Databases

   Many of the details associated with processing IP traffic in an IPsec
   implementation are largely a local matter, not subject to
   standardization.  However, some external aspects of the processing
   must be standardized, to ensure interoperability and to provide a
   minimum management capability that is essential for productive use of
   IPsec.  This section describes a general model for processing IP
   traffic relative to security associations, in support of these
   interoperability and functionality goals.  The model described below
   is nominal; compliant implementations need not match details of this
   model as presented, but the external behavior of such implementations
   must be mappable to the externally observable characteristics of this
   model.
----------------------------------------------------------------------

> So as part of the revised processing model we need to remove the
> old, 2401 restriction and explain what the new model does and why.

Does the new processing model require interface selectors or not? Does
it help describing the processing model if we have interface selectors
instead of per interface SPD?

What is the rationale behind this change?

> this will also be covered i the revised model.

I would really like to have that revised model as soon as possible...

> work this way!

That was what we were refereing to, i.e while we fix the issue 47, it
will make clear that we do not need protocol ranges in the SPD, but we
do need each SPD entry to have list of selector items (source and
destination ip-address ranges, protocol id, source and destination
port ranges).

> So, we are revising the characterization accordingly. 

Yep, and as this will be taken care of inside the Issue 47, then we
can reject the issue 69 proposing about the same thing, but
differently. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Oct 2003 12:49:16 +0300

> fragments (separate SAs for them) is rejected?

The proposed resolution in issue 49 is:
----------------------------------------------------------------------
Proposed resolution:

	Because of this limitation, we do not plan to change 2401 to make
	provision for receipt of red side fragments as a special case.
----------------------------------------------------------------------

I.e there will not be special flag for SA that means that red
fragments OK for this SA. So if red fragments are not going to have
special inbound handling the issue 81 which proposed creating special
SA for outbound to them should be reject too.

So the special treatment was proposed. I don't think we have any issue
in the issue tracker about whether the 2401bis should or should not
permit red-side fragmentation.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Oct 2003 09:44:09 -0400

>RFC2401 restricts anybody in that way.

correct.

when I published my first draft of the new model, it had a way to tag 
a packet with a VID, for forwarding purposes, and because we still 
had a per interface SPD, the VID selected the SPD too. The VID is not 
a selector, per se.  However, as I have listened to comments from 
various folks I am less convinced that we should have per-interface 
SPDs as a basic part of the model. Instead it seems more important to 
have a function to select an appropriate SPD, if more than one is 
needed, and to leave the forwarding decision as a separate matter.

>What is the rationale behind this change?

the rationale is that if we do not need to impose the constraint of a 
per-interface SPD, then it should go away, and a more flexible way of 
specifying the SPD should be accommodated, explicitly.

>I would really like to have that revised model as soon as possible...

me too :-)

>destination ip-address ranges, protocol id, source and destination

agreed, and thanks for the clarification!

OK.

Steve

---

From: Mark Duffy <[email-masked]>
Date: Fri, 17 Oct 2003 17:31:33 -0400

At 12:49 PM 10/15/2003 +0300, Tero Kivinen wrote:
...
>permit red-side fragmentation.

Hi all,

I would like to request that 2401bis lift the prohibition on red-side 
fragmentation by SG, BITS, BITW.

Red side fragmentation when employed can reduce the reassembly burden on 
the IPsec receiver, and with it some potential for DOS attack.  It can also 
increase the performance of the overall solution, by distributing the 
reassembly burden to end hosts.  I know of at least one vendor that offers 
a red-side fragmentation option now, and I believe that other vendors do so 
as well.

After applying red-side fragmentation, the IPsec device would evaluate the 
SPD for each fragment just as though the fragments had been received from 
the black side.  Fragments not containing port numbers can only match a 
rule with port selectors equal to "wildcard" or "opaque", or rules for 
protocols where port numbers are not used.

Since this behavior is pretty much indistinguishable from fragmentation 
that may occur anyway upstream of the IPsec device, I do not see any reason 
to disallow it.

I propose text such as the following, added somewhere in the outbound 
processing description:

     An SG, BITS, or BITW implementation MAY fragment packets before
     applying IPsec.  The device SHOULD have a configuration setting
     to disable this.  The resulting fragments are evaluated against
     the SPD in the normal manner.  Thus, fragments not containing port
     numbers may only match rules having port selectors of "opaque" or
     "wildcard".

Thanks, Mark

P.S. Issues 49 and 81, which requested *special handling* for red-side 
fragmentation have been rejected.  This request is NOT the same as those 
and is in fact much simpler.