Subject: [bmwg] [bwmg] comments on draft-ietf-bmwg-ipsec-meth-01

From: "Jason Guy \(jguy\)" <[email-masked]>
Date: Wed, 20 Sep 2006 11:27:01 -0400

Tim & Merike,

I have read the draft, and I have a few comments, and some questions:

Section 2 mentions NAT is out of scope.  NAT Traversal (NAT-T) will
cause the Phase 1 SA to be handled differently, and possible will affect
the performance of IKE.

Section 6.6 talks about the parameters of the security context.  

PFS should be added to this list of parameters.  I believe PFS would
definitely affect the setup rates, and rekey performance.

Furthermore, I think both PSK (pre-shared keys) and PKI need to be
addressed.  This will also affect the rekey performance of the SA's.

Section 6.1.1 mentions the L4 protocol set to 255 "reserved".  Why does
this ensure max space?

Section 6.6.1 discusses the IPSec transform sets, however, I do not see
a section regarding the IKE policy definition.  I would think the use of
RSA-sig, or PSK will affect the Phase 1 performance.

Section 6.6.6, I would recommend citing RFC2401 section 4.4.2 which
defines the selectors.  This will eliminate any question what is meant
by IPSec selector.

Section 7.1 says in the reporting section "The reporting format SHOULD
be the same as listed in 7.1...".  It seems like many of the sections
from 7 to 14 have errors in the reference to other sections in the
document. I think these are copy paste errors, or they should refer to
2544 section 26.x. Here is the list of errors I gathered:
- In section 7.1, 7.2, 8.2, 8.3, 8.4, etc, the reporting section always
refers back to the reporting of 7.1.  
- Section 9.2-4 refer to section 8.1 reporting section.  
- Section 11.2-5 refers to section 10.1 reporting section. 
- The remaining reporting sections also shows this same problem.
- Section 11.5 Procedure refers to the procedure in 10.2.
- Many of the reporting sections refer to section 5.6 for security
parameters.  I do not see a section 5.6 here.

I have a general comment before getting into the tests themselves.  I
have actually struggled to understand how the benchmarking of the Phase
1 piece is possible without the impact of Phase 2.  In many of the IKE
tests, the IPsec SA's are established, and packets are sent.  So does
this really test the performance of IKE?

Section 7.1 and 7.2 seem to basically be the same test.  

Section 9.1 procedure refers to sending a stream of frames for at least
120 seconds.  I think the time duration of the stream would not matter
to the latency.  Each frame will experience latency, and it should be
measured on a per packet basis.  There should be a requirement to the
number of frames sent to get a decent sample set however.  I realize
2544 defines a method for determining the latency, but the test tools
can typically measure the (average, max, and min) latency, jitter, and
other qos related measurements.

Section 11.5 procedure is not clear.  It refers to the procedure of 11.1
(I believe), but then specifies the rekey interval to be 1/3 the trial
duration in 11.1.  The trial duration is not specified in 11.1, just the
frame rate, so it is not possible to define the rekey interval in 11.5.
The premise is fine, though the procedure should indicate trial duration
for the 11.1 procedure, and additionally mention the rekey should be 1/3
of this interval.  It also mentions 1/3 of the bytes, and this part is
fine since we should know the frame rate we are going to send.  Are we
trying to cause 3 rekeys over the course of the trial?

Section 13 uses the formula:
Setup Rate = n / [Duration of Test - (n * frame_transmit_time)] n = # of
tunnels frame_transmit_time = the time it takes 1 frame to transmit end
to end?
Duration of test = total time the trial runs for?

So, for all of the calculations, it seems we are trying to find the time
frames are being forwarded, subtracting the remaining time, and
averaging across all SAs.  This is ok, but most systems can transmit
frames, and work on building the SA at the same time.  So, how do you
control for the parallelism?  It can hide inefficiencies in a given
implementation.

Section 13.2 does not indicate how the test tool will know the IKE phase
1 is established.  Assuming the test tool will be able to bring up the
phase 1 SA without doing phase 2, why does the packet size or throughput
matter?  The IP packet should trigger the SA to be built, and that is
all. The phase 2 tunnels are not going to be built and the packet will
not go anywhere.  I realize testing IKE phase 1 alone is difficult to do
without also doing phase 2.  
Does IPsec lifetime matter for this since we are focusing on phase 1?  
The problem with using the frame-transmit time is the setup rate will
include the combination of phases 1 and 2 setup times, so we have not
isolated the phase 1 setup time.

Thanks,
Jason

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg