Subject: [Ipsec] FW: Remaining issues for IKEv2

From: "Charlie Kaufman" <[email-masked]>
Date: Mon, 10 May 2004 16:02:13 -0700

Resend... this apparently got lost

-----Original Message-----
From: Charlie Kaufman 
Sent: Sunday, May 09, 2004 10:44 PM
To: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 11 May 2004 12:38:30 -0400

> Resend... this apparently got lost

Charlie, if you can send me (privately) a copy of your original e-mail
that someone got lost, I'll try to track down what happened to it.
The SPAM filters only kick in if it was posted from some address other
than the one which you receive the IPSEC mailing list from; at that
point, they go into a mailman holding pen for review.  For those who
are interested in the process, we get somewhere around 500 to 600
(!!!) messages from non-mailing recipients a day.  99.99% of them are
spam (I think I've detected 3 false positives since we transitioned
over to [email-masked]).  Of those several hundred (very) potential
spam messages, first I filter off anything which has a spam score of 7
or higher according to the ietf.org mailer.  This removes
approximately 30% of the messages.  Next, I run the messages through a
spamassassin with a Bayesian filter, which has been specifically to
recognized IPSEC wg mail as good stuff.  This reduces what's left to
approximately a dozen messages which I inspect by hand, and in most
cases it's spam which then gets fed to the Bayesian classifer.  In the
rare case where someone sent a legimate message, I determine what
sender address was used, and then add it to the [email-masked] as a
no-mail mailing member.  This effectively whitelists the sender
address.  

It seems rather unlikely that your message would have been caught as
spam, but we can double check and make sure you didn't get unlucky
somehow.  In particular, if you were posting from home and might have
been using another e-mail address as the sender, we can make sure that
gets whitelisted, which should avoid the problem altogether going forward.

						- Ted

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 11 May 2004 12:38:30 -0400

- Ted

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 11 May 2004 14:04:39 -0400

> been easier to just accept these proposals than to argue. One last

I've looked through both archives and the VPNC mailing list, and I
can't find this proposal.  Was it actually sent to the entire ipsec
mailing list?  In any case, I tend to agree with previously expressed
sentiments that absent a very strong, compelling need to make changes
in the crypto core of IKEv2, it is long past time to shoot the
engineers and ship the product.

> that agreement in IKEv2. My (perhaps oversimplified) understanding is as

What consensus we have for fragment handling is described in section 7
of draft-ietf-ipsec-rfc2401bis-02.txt, which describes multiple
approaches, some of which will be mandatory and some which will be
optional (although we do not consensus on whether the optional
approaches should be "MUST", "MAY" or "SHOULD").  Since one of the
approaches requires the use of the OPAQUE encoding, my suggestion is
that we define OPAQUE in ikev2, possibly using the reversed 65535-0
range as you mentioned earlier, and then include a pointer to
RFC2401-bis.

Before anyone points this out, I agree that it's unfortunate that we
have had to settle for documenting multiple approaches to handling
fragmentation, since this represents an unfortunate complication of
the standard.  The problem fundamentally is that different potential
users of IPSEC have expressed different constraints.  Some folks,
exemplified by Steve Kent, have talked about a desire to use
high-speed IPSEC engines, where mandatory stateful inspection of
fragments would be a major performance problem.  Others, such as Tero
Kivinen, want to be able to enforce policies where some all data sent
to certain ports MUST be encrypted, while all data sent to other ports
MUST NOT be encrypted, but perhaps only integrity protected.

Unfortunately, we aren't quite done with the fragmentation issue, as
the area where we do not have conensus js whether the various
approaches should be tagged MUST, MAY or SHOUD.  We seem to all agree
that Approach #1 should be a MUST, but there was at best very rough
consensus of #2 being MAY and #3 being SHOULD.

So what I propose to do to move this forward is to hold a straw poll.
Of course, 75% of the work of holding a straw poll is to determine the
correct questions to ask.  So what do people think of the following
formulation:

	Which of the following requirements woudl you be willing to live with?
	(You may select more than one):

	A)  Method #2 (fragments to a separate SA) is a MUST
	B)  Method #3 (stateful fragment inspection) is a MUST
	C)  Both #2 and #3 is a SHOULD
	D)  Method #2 is a MAY, Method #3 is a SHOULD
	E)  Method #3 is a SHOULD, May #2 is a MAY

As I mentioned, there seemed to be someone rough consensus over D: #2
as MAY, #3 as SHOULD, but it was by no means unanimous.

						- Ted

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 11 May 2004 14:04:39 -0400

- Ted

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 15 May 2004 17:15:14 -0700

At 2:04 PM -0400 5/11/04, Theodore Ts'o wrote:
>the standard.

Exactly right.

>So what do people think of the following
>formulation:
>

There is a more logical choice, which would be:
	F)  Method #2 is a MAY, and Method #3 is a MAY

We don't need another MUST or SHOULD to aid interoperability, since 
we already have a MUST for #1. We have zero experience with these new 
proposals for how to deal with fragmentation. Neither proposal should 
be even a SHOULD in 2401bis.

It is likely that some vendors will support one and/or the other in 
2401bis deployments, and after they do, we will have a better idea 
about whether either is feasible and useful in real implementations; 
we can use that experience in changing the requirements levels in 
2401bisbis. Until then, they should both be limited to MAY, 
indicating no preference for either from the specification.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 15 May 2004 17:15:14 -0700

Exactly right.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 May 2004 15:13:25 +0300

> >	E)  Method #3 is a SHOULD, May #2 is a MAY

What is the difference between D and E. Should the E be "Method #2 is
SHOULD and Method #3 is a MAY"?

Anyways I can accept method #3 being SHOULD, MAY or even MUST, and
Method #2 being MAY.

> 	F)  Method #2 is a MAY, and Method #3 is a MAY

Which is to say we do not have any preferred method for fragments when
using port selectors. I would really like to have one method SHOULD
(and that being method #3).

> be even a SHOULD in 2401bis.

Our implementation have been using method #3 since year 1998, so there
is some experience with that. I do not know if others do that, but my
guess is that there is also other implementations doing same. For the
#2 there is no experience, as it do require OPAQUE support, thus there
is no way to negotiate it in the IKEv1.

The case #3 can be simply be used without any prior negotiation or
configuration, and if both ends support it then packets will go
through. 

> indicating no preference for either from the specification.

I can already say that #3 is feasible. If it is useful, that I cannot
say, as most of the people do NOT use port selectors at all.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 17 May 2004 15:13:25 +0300

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 18 May 2004 10:54:52 -0700

>Anyways I can accept method #3 being SHOULD, MAY or even MUST, and

Certainly not a MUST; it really isn't needed for interoperability. It 
is quite conceivable that many systems would only want to work with 
ANY, and not need either #2 or #3.

>configuration, and if both ends support it then packets will go

But the negotiation is a pretty important part of #3. I see your 
point about wanting one of #2 or #3 to be a SHOULD, but I think it is 
still way too early to prefer one, and I think it's too early to 
guess that one will work better than the other.

It is appropriate when going from Proposed to Draft to change some of 
the requirements. Maybe leave both of these MAYs for now with the 
intention of upping one or both to SHOULD when the document advances.

>say, as most of the people do NOT use port selectors at all.

A very good reason to wait until there is more experience. I suspect 
that the new discussion in 2401bis will cause some developers to pay 
much more attention to this and possibly exposed it more to their 
customers. The results of that (or the continued lack of interest) 
will be valuable.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 18 May 2004 10:54:52 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Thor Lancelot Simon <[email-masked]>
Date: Tue, 18 May 2004 19:31:09 -0400

> (and that being method #3).

I concur.  We should recommend (or even mandate) something in this area, I
believe.

Thor

---

From: Thor Lancelot Simon <[email-masked]>
Date: Tue, 18 May 2004 19:31:09 -0400

Thor

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 May 2004 10:58:46 +0300

> ANY, and not need either #2 or #3.

One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST. In
the RFC2401 it was SHOULD. I think it should follow the same selection
we have here for #2, i.e.. MAY or SHOULD. 

> But the negotiation is a pretty important part of #3. I see your 

No, not really. Negotiation is only needed if there is another way to
do it, i.e. if the #2 is defined. Int IKEv1 there was no way to use
#2, as you could not negotiate OPAQUE, thus there was no other way to
get fragmented packets with port selectors through. 

> guess that one will work better than the other.

Might be. I was simply commenting that we do have experience of the
statefull inspection case, so if we use running code as an guideline
which to make SHOULD, we at least have some running code for the case
#3.... 

> intention of upping one or both to SHOULD when the document advances.

No, I do not think we need MAY+ there now... If they are MAYs then
they are MAYs, and thats it. Lets make the decision now and then
accept that. 

> customers. The results of that (or the continued lack of interest) 

So I assume that your vote would be on both on being MAY?

My preferred way would be #3 being SHOULD and #2 being MAY. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 19 May 2004 10:58:46 +0300

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 19 May 2004 07:56:31 -0700

At 10:58 AM +0300 5/19/04, Tero Kivinen wrote:
>One wierd thing it thas 4.4.1.1 says support for OPAQUE is MUST.

Then that *needs* to be corrected in the next version of the draft.

>So I assume that your vote would be on both on being MAY?

Correct.

>My preferred way would be #3 being SHOULD and #2 being MAY.

That makes some sense too; it's just more adventurous than I would be 
with this protocol without a lot more support from other vendors.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 19 May 2004 07:56:31 -0700

Correct.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 May 2004 10:18:50 -0400

>Then that *needs* to be corrected in the next version of the draft.

Support for the selector type in the SPD is trivial, and if we 
mandate support for OPAQUE now, then we're set for later elevation of 
one of these options to SHOULD from MAY, for example.

>That makes some sense too; it's just more adventurous than I would 
>be with this protocol without a lot more support from other vendors.

I agree with Tero that #3 as SHOULD is appropriate. My only concern 
re #3, as Ted noted earlier, is that it imposes an unacceptable 
burden on high speed implementations. Thus, if #3 is SHOULD, then I 
think it would be legitimate for such implementations to not support 
it (consistent with the interpretation of SHOULD).  I would like 
these implementations to support #2 in that case. A statement that an 
implementation SHOULD support either #2 or #3 might be one way of 
expressing this notion.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 May 2004 10:18:50 -0400

Steve

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 20 May 2004 10:01:41 -0700

At 10:18 AM -0400 5/20/04, Stephen Kent wrote:
>mandate support for OPAQUE now, then we're set for later elevation 
>of one of these options to SHOULD from MAY, for example.

True, but I worry about mandating the ability for a 2401bis system to 
support a selector type when it doesn't support the mechanics that 
goes with the selector. It gets tricky in 2401bis because the new 
fragmentation ideas are spread throughout the document. We might just 
have to live with that.

>it (consistent with the interpretation of SHOULD).

Agree. Not following a SHOULD because you know that you won't be able 
to consistently figure out where the fragment would go is perfectly 
legitimate.

>   I would like these implementations to support #2 in that case. A 
>statement that an implementation SHOULD support either #2 or #3 
>might be one way of expressing this notion.

A very good suggestion. The paragraph currently at the end of page 49 
could be changed from:
     To address the above requirements, three approaches have been
     defined:
To:
     To address the above requirements, three approaches have been
     defined. Implementations MUST support method #1 below, and SHOULD
     support method #2 or method #3 (or both).

Editorial suggestion: breaking out the three proposals as subsections 
(7.1, 7.2, 7.3) would make it easier to read, particularly if you add 
more text to them.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 20 May 2004 10:01:41 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 May 2004 13:33:47 -0400

At 10:01 AM -0700 5/20/04, Paul Hoffman / VPNC wrote:
>True, but I worry about mandating the ability for a 2401bis system 
>to support a selector type when it doesn't support the mechanics 
>that goes with the selector. It gets tricky in 2401bis because the 
>new fragmentation ideas are spread throughout the document. We might 
>just have to live with that.

I appreciate the concern.  We are working on the next rev and found 
another place where OPAQUE seems appropriate (not for fragmentation 
support), which would be another reason to include it, if the WG 
agrees with the added material that refers to OPAQUE.

>>think it would be legitimate for such implementations to not 
>>support it (consistent with the interpretation of SHOULD).
>
>Agree. Not following a SHOULD because you know that you won't be 
>able to consistently figure out where the fragment would go is 
>perfectly legitimate.

I'm always encouraged when we agree :-)

>A very good suggestion. The paragraph currently at the end of page 
>49 could be changed from:

again, great!

>Editorial suggestion: breaking out the three proposals as 
>subsections (7.1, 7.2, 7.3) would make it easier to read, 
>particularly if you add more text to them.
>

Thanks for the suggestions,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 May 2004 13:33:47 -0400

again, great!

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 May 2004 15:05:57 +0300

>      support method #2 or method #3 (or both).

I can also live with that proposal....

> (7.1, 7.2, 7.3) would make it easier to read, particularly if you add 

Definately. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 May 2004 15:05:57 +0300

Definately. 
-- 
[email-masked]