Re: [bmwg] IPsec drafts

Hi Merike,

thanks for your extensive response. Comments interspersed (I have 
removed items that need no further discussion).

    Yaron

Merike Kaeo wrote:

> Hello Yaron......thanks for thorough read......comments 
> embedded......Tim may have things to add as well.....
>
[deleted]
>> - IPsec "gateways" are mentioned multiple times but are not defined.
>> They are another synonym to "IPsec server".
>
> We assumed that this would be a commonly known term as defined by the 
> IPsec standard.  Specifically,
> from RFC 4301 in section 3. System Overview:  "An IPsec implementation 
> operates in a host, as a security gateway
> (SG), or as an independent device, affording protection to IP traffic. 
> (A security gateway is an intermediate system implementing
> IPsec, e.g., a firewall or router that has been IPsec-enabled.)"
This is not a very good answer since you do define things like ISAKMP, 
IKE, IPsec, SA etc. :-) And I think the definition is material to 
understanding the methodology.
>
>> - I would expect the "security context" to indicate NAT traversal, since
>> it has performance implications.
>
> I agree that this should be added.  I think it would fit best under 
> the IKE context at the end of the section and would be an additional 
> MUST.
> Will this be acceptable?
>
Yes. By the way, doesn't the detailed definition of the Context belong 
in the normative Methodology draft?
>> - IPsec Tunnel Capacity: it is implicit here that each IPsec SA is
>> associated with exactly 1 IKE SA. Please make it explicit.
>
> I agree.  So is it sufficient to change the discussion section to:
>
> "  This metric will represent the quantity of IPsec Tunnels
>       that can be established on an IPsec Device that can forward traffic
>       i.e.  Active Tunnels.  It will be a measure that indicates how
>       many remote peers an IPsec Device can establish a secure
>       connection with.  For IPsec Tunnel Capacity, each IPsec SA is 
> associated
>       with exactly 1 IKE SA. "
>
Sounds good.
>> - IPsec throughput: the definition is unclear. The units are pps, but
>> then there is reference to the packet size.
>
> I don't understand what is unclear?!?  What would you change?
>
The text is a bit obscure, in that you first describe two measurement 
options and then say the 2nd one is the "right" one. But more 
importantly, when you say "This resulting rate can be recalculated with 
an encrypted framesize to represent the encryption throughput rate" this 
seems to mean that the rate somehow depends on the framesize, which is 
incorrect - you only measure PPS. Note that RFC 1242 actually mentions 
*both* PPS and BPS as the measures of throughput - which again is rather 
confusing.

[deleted]
>
>> - 10.8.1: there are DOS resistance solutions where the device *never*
>> stops accepting all valid attempts, it just accepts fewer and fewer. I
>> would suggest to qualify the measure, e.g. "the rate of invalid or
>> malicious IKE tunnels that can be directed at a DUT before the Responder
>> ignores or rejects more than 90% of valid tunnel attempts".
>
> There is no rate.  We are testing how many failed attempts are 
> possible while still being able to establish
> the valid IKE message.  Need to think on this a bit......your 
> suggestion would change the nature of this test.
>
My point here (and elsewhere) is that DOS protection is typically not 
all-or-nothing. You can measure the rate where the DUT *starts* failing 
valid requests, but it's not very interesting.
>
>> - 10.8.2: why is this called "Phase 2"? It is simply DOS resistance at
>> the ESP/AH level. It could even apply to manually configured ESP/AH. In
>> addition, the measure's definition is far from precise.
>
> You are right that it should not be Phase 2.  However, what would you 
> propose to make definition more precise?
Again, you imply in the discussion that once the first packet is lost, 
the DOS attack is deemed successful. Moreover, you don't mention whether 
this test should be done at the top throughput of the device.

I suggest to change the definition to: The ESP/AH Hash Mismatch Denial 
of Service (DoS) Resilience Rate quantifies the rate of invalid ESP/AH 
packets that a DUT can drop without affecting the traffic flow of valid 
ESP/AH packets. "Affecting the flow" is defined as dropping more than 1% 
of valid packets. The test report should include (1) the total 
throughput of traffic, which should be as close as possible to the DUT's 
IPsec throughput, and (2) the rate of invalid packets out of the total.
>>
>> Methodology draft
>> - NAT traversal is mentioned, but there is no requirement to actually
>> measure it.
>
> Not everyone necessarily supports NAT traversal.  It was an extension 
> for IKEv1 so not really a part of the protocol.  Also note that for 
> IKEv2 the NAT Traversal support is optional.  (and there will be a 00 
> rev of IKEv2 draft soon - there is a new IKEv2 clarification doc so 
> I'm trying to be thorough and get nuances between IKEv1 and IKEv2 that 
> are relevant to performance)
Formally you are right, but NAT traversal is widely supported and of 
course is essential for remote access VPNs. So can we have an optional 
test to cover it?
>
>
>> - Why is support of AH a MUST?
>
> Well.....this is something we actually want input on.   While the 
> IPsec docs say AH MAY be supported, there is in reality little to no 
> testing done with AH.  Some folks in v6 community are trying to bring 
> back AH.  And RFC4305 (cryptographic algorithms for ESP and AH) 
> specifies algorithms for both protocols.
>
> Do you think it would be better to say ' If AH is supported by the 
> DUT/SUT  testing of AH Transforms 1 and 2 MUST be supported.' ?  We 
> don't say anywhere else that you MUST test AH, just that in any test 
> you must have either an AH an/or ESP transform.
I like the new wording much better.
>
>
>> - Why is ESP Transport mode a MUST? It is inapplicable to IPsec 
>> gateways.
>
> An IPsec gateway can act as an IPsec end node.  To make it easier for 
> everyone here's the text from section 3.3 of RFC4301:
>
>  " A host implementation of IPsec may appear in devices that might not
>    be viewed as "hosts".  For example, a router might employ IPsec to
>    protect routing protocols (e.g., BGP) and management functions (e.g.,
>    Telnet), without affecting subscriber traffic traversing the router.
>    A security gateway might employ separate IPsec implementations to
>    protect its management traffic and subscriber traffic.  The
>    architecture described in this document is very flexible.  For
>    example, a computer with a full-featured, compliant, native OS IPsec
>    implementation should be capable of being configured to protect
>    resident (host) applications and to provide security gateway
>    protection for traffic traversing the computer. "
This is true. But even if it's implemented, it's not a core function. 
And the text you're quoting doesn't mandate it. So let's make it optional.
>
>> - The purpose of Table 3 is unclear, given that results are reported
>> separately for ESP and AH.
>
> This is a scenario for nested tunnels which may be used (and are used 
> in some environments in practice).  Note that
> in v6 it is less likely to use NAT traversal and therefore some folks 
> are trying to argue for using AH.  Note that this is
> just a RECOMMENDED test but we as authors felt reasonable to mimick 
> what folks in real world are doing.  if your
> experience is different, please let's discuss.
We are seeing little use for this kind of tunnels. But if it's optional, 
fine.
>
>> - 9.1: why does the procedure for the baseline test refer to IPsec SAs,
>> where the test is only of cleartext traffic?
>
> The IPsec SA selectors refers to IP addresses and port 
> numbers.......so want to ensure same type of traffic is sent for baseline
> as for tests utilizing IPsec.
>
Makes sense. Could you add this clarification to the document?
>
>> - 9.1: "advertising copy" and "product datasheet" are clearly out of
>> scope. Vendors are free to publish results in whatever way they choose,
>> including shouting them down a well.
>
> I'd like to hear other comments on this.  Is there anything wrong with 
> how the reporting format is written?  The intent was to
> make sure reports from different vendors and/or testing environments 
> can accurately be compared.
>
I would just say, you have two reporting options and here they are (and 
maybe that one is preferred). Realistically, the IETF cannot mandate 
publication of anything.
>
>> - 11.2: measuring IPsec frame loss implies that we allow frame loss. So
>> what percentage loss do we allow in e.g. throughput tests?
>
> Huh?  The throughput is the fastest rate at which the count of test 
> frames transmitted by the DUT is equal to the number of test
> frames sent to it by the test equipment.  This is not necessarily the 
> maximum rate for the frame size on the input media.  Should be for
> wire rate performance but may not be true for all frame sizes :)
>
> Or am I misunderstanding this question?  The procedure looks fine to me.
>
Now I understand better but I still have an issue: a software IPsec 
device might be running on a box with 10Gb interfaces, but still be 
specified for lower throughput. I see no reason to measure packet loss 
for a level of throughput that you don't support. I suppose the wording 
can be changed to mention "nominal device throughput" instead of "frame 
rate on input media".

>
>> - 11.2: assuming DUTa and DUTb are identical, this measures some
>> function of a single device's loss rate, maybe simply twice the rate.
>
> Can you elaborate?   What is missing in procedure or reporting format 
> from your perspective?
>
What I'm saying is that you cannot calculate packet loss on *one* device 
from the packet loss measured on a chain of two identical devices, both 
of which may be dropping packets. On a related theme, I would appreciate 
a paragraph added near Figure 2 on whether and when you can replace DUTb 
by a more powerful device (where appropriate of course), which seems to 
be a common practice. E.g. you encrypt on a small home router and 
decrypt on a large enterprise router, and expect all the bottlenecks to 
come from the smaller device.
>
>> - 11.5: this test only generates 2-3 rekey events if using a single
>> (IKE) SA, why not define it with a lower SA lifetime or a higher number
>> of SAs?
>
> The intent was to only have a few rekey events during the testing.  
> Why would you want more?
> Is there a test scenario that you want that we are not covering?
I just expect packet loss to be typically zero with such a low rekey 
rate. But maybe I'm being optimistic...
>
>
>> - 15.1: as noted for the terminology draft, this DOS test will not work
>> well with randomized anti-DOS mechanisms.
>
> So is it enough to have the statement in the terminology doc or did 
> you want something added in this section?
>
I suggest to also have it here.
>
>> - 15.2: this test may completely fail if the maximum throughput is
>> unstable, in the sense that *any* extra CPU activity would cause packet
>> loss. Maybe it should be tried first at 90% of max throughput.
>
> I think it will be important in real life to see what happens at 
> throughput rates.  However, if a device completely
> fails then the test MAY also be repeated at various Tunnel scalability 
> data points.   Do you think we need to make the
> scalability points more an exact statement (i.e. 90%)?   Although this 
> makes me think we also need to change
> the reporting format to:
>
> " The results shall be listed as PPS (of invalid traffic) . The 
> Security Context Parameters defined in Section 7.6
>   and utilized for this test MUST be included in any statement of 
> performance.  The aggregate rate of both microflows
>   which act as the offered testing load MUST also be reported."
>
The new text is fine, also please make scalability points (e.g. 90%) 
explicit.
>
> - merike
>
>
> Scanned by Check Point Total Security Gateway.
>
_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www.ietf.org/mailman/listinfo/bmwg

Re: [bmwg] IPsec drafts - comments