[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ipsec] FW: Remaining issues for IKEv2



Resend... this apparently got lost

-----Original Message-----
From: Charlie Kaufman 
Sent: Sunday, May 09, 2004 10:44 PM
To: ipsec@ietf.org
Subject: Remaining issues for IKEv2

There are currently 14 open issues in the issue tracker database re:
IKEv2. I believe four others have been raised on the list but are not in
the issue tracker.

Of the 18, six (#101, #102, #104, #105, #106, and #107) are requested
changes to the IANA initial database I-D, six (#94, #97, #99, #100, #103
and one unnumbered) contained proposed text or were specific enough that
I have updated the IKEv2 I-D, three (#95 and two unnumbered) I believe
should be rejected, and for the remaining three (#96, #97, and one
unnumbered) I need guidance.

Possible sources of controversy:

Done:

The unnumbered one that I've updated is from Ted Ts'o's message of
4/6/04 proposing that the phrase "to pass an account name or" be removed
from the definition of ID_KEY_ID.

Not done, recommend reject:

#95 involved having an optional variation of the EAP authentication
exchange that is two messages shorter. There was limited discussion on
the list, but most of that was negative.

Proposal by Yoav Nir 4/14/04 to support periodic reauthentication. This
proposal came after the end of IETF Last Call and would add complexity
to the protocol. Recommend this be considered as an optional extension
if anyone is motivated enough to pursue it.

Apparent inconsistency pointed out by Peter Brubmair on 4/30/04 that
Appendix B talks about five Diffie-Hellman groups but only defines four.
The fifth was removed in revision -09 because it is defined in
[ADDGROUP]. The wording could be clearer, but it wasn't obvious how (to
me), and I don't believe it is technically wrong. Recommend no change.

Need Guidance:

Proposal by Pasi.Eronen supported by Hugo Krawczyk on 3/30/04 to change
the computation of the AUTH payload. This is yet another "gilding the
lily" crypto modification. I am confident it adds no cryptographic
strength to the protocol and it breaks compatibility with anyone who has
implemented this stuff already, but it adds only trivial complexity to
the protocol and a trivial computational overhead. In the past, it's
been easier to just accept these proposals than to argue. One last
time??

Handling of OPAQUE. (#96 and #98). An agreement has been reached on the
handling of fragments in RFC2401bis, but it's not obvious how to reflect
that agreement in IKEv2. My (perhaps oversimplified) understanding is as
follows:

The problem arises because IPsec SAs can be limited to specific ports of
TCP and UDP and a single pair of endpoints can have different SAs for
different classes of traffic. If the sending endpoint needs to forward
an IP fragment other than the first, it may not be able to determine
what port the reassembled packet will contain and therefore may not know
which SA to forward it on (or whether to forward it at all). In some
cases, the sending endpoint will know to which port the fragment is
destined (either because it did the fragmentation or because it has
already forwarded the first fragment and kept state to recognize
subsequent ones). In that case, it would be most natural to send the
fragment on the "correct" SA. In some cases, the sending endpoint will
not know to which port the fragment is destined. In that case, it must
either discard the fragment, guess the correct SA, or have an SA
designated as carrying non-initial fragments.

The receiving endpoint faces a corresponding decision. When it receives
a non-initial fragment on an SA willing to accept traffic for some ports
but not others, it can either forward the packet or discard it. It may
have kept enough state to know whether this fragment is destined for an
allowed port or it may not.

The question for IKEv2 is: what indication (if any) of fragment handling
policies should be included in the IKEv2 negotiation. The choices are:

1) None. If the sending endpoint forwards a fragment on an SA
unacceptable to the receiving endpoint, the receiving endpoint discards
it and the connection with fragmentation likely fails. This behavior can
be avoided either by having the endpoints use the same scheme for
directing fragments or by having the receiving endpoint generously
accept fragments on any SA that accepts any ports of the protocol.

2) Explicitly negotiate a fragment carrying SA. Add some syntax to
traffic selectors that allows an SA to negotiate the ability to send and
receive fragments with unknown port (OPAQUE). This might be supplemented
with some ability to negotiate whether non-initial fragments can
alternatively be sent on the same SA as the initial fragment. One
proposed encoding is a (previously invalid) port range of 65535 - 0 as
indicating acceptance of non-initial fragments.

3) I'm sure there are other possibilities as well.

My recommendation is (1), with a short explanation of the situation and
a pointer to RFC2401bis, but I'm open to other options.

	--Charlie

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec