[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2401bis issues
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
Rejected Issue 40 ("Interface SPD selector vs. per-interface SPD")
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.
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.
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
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.