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