Re: 2401bis issues

[Stephen Kent <kent@bbn.com>]

At 12:32 -0400 10/14/03, Angelos D. Keromytis wrote:
>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.

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.

>
>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.

this will also be covered i the revised model.

>
>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.

OK.

>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").

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.

>
>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.

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

Steve