[IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt
Sean Shen writes: > Hi, IPSECME WG, > The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The > modification addressed comments we received so far and also include some > other editing. > Major changes are as following: > #4 > Section 3.2 > Added clear reference to rfc4302 and rfc4307 for integrity requirement and > algorithm choice. I do not think it is good idea to copy the table from RFC4307 as it is likely to change in the future, so better would be just to give reference to the document. On the other hand RFC4306 already says that "... implementations MUST NOT negotiate NONE as the IKE integrity protection algorithm ..." (section 5. Security Considerations of RFC4306), thus AES-CTR cannot be used without integrity algorithm in this context anyways. One thing that is not 100% clear from the draft is that whether there is any padding in the encrypted payload. RFC4306 says that encrypted part is padded up to the block size of the cipher. In AES-CTR the block size is 1, thus that does not require any padding. Normal ESP requires padding for at least up to 4-byte boundary, regardless of the block size of the cipher, thus even AES-CTR uses padding up to 4-byte boundary. The IKEv2 SA does not require thus. I think it would be better to add text explictly saying this. I.e. add text like this to the end of 2.3: ... For this reason, AES-CTR does not require the plaintext to be padded to a multiple of the block size. For Encrypted Payload this means that Padding field is always empty, and Pad Length field will always be 0. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-00
Hi everyone, As a general comment, this document got me thinking whether pseudo-code can be made amenable to some minimal level of validation. For example, there is so much code here that I could never be sure that all "goto"s are referencing valid labels. If any member of this list is a aware of such a solution, I would be interested to know. - Sec. 5. In the definition of IPsec flows, how is this done for (typically tunnel mode) UDP-encapsulated ESP? Are port numbers part of the flow definition? This text belongs either here or in Sec. 8. - 5. "Unsure" - if we choose the option of dropping such packets, are there cases when retransmitted packets do not add any information and we will remain forever "unsure"? - 6, first paragraph. in to -> into - 6. This section seems to discuss the construction of an ESP-null detection engine out of an off-the-shelf DPI engine. If this is the case, please say so. - 9.1. 160, 192, and 256 bit algorithms are used -> 160, 192, and 256 field lengths are used - 9.1. "Payload Data" is starred for some reason, probably cut-and-paste. - 10. The Security Considerations needs to have an explanation of what this is good for, i.e. what security policy is enforced, what kind of DPI is done. Also, (malicious) traffic can be encrypted in multiple ways, e.g. simply by using TLS on top of TCP. In addition, we need to note the DOS potential of the ESP-null detection process. - Pseudocode: are we assuming one protocol per SPI? At a higher level, shouldn't we have processing for tunnel mode ESP as well? - Pseudocode: retreaved -> retrieved Thanks, Yaron smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Relating the two ESP-null documents
Works for me! Thanks, - Ken >-Original Message- >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >Of Yaron Sheffer >Sent: Tuesday, August 11, 2009 6:04 AM >To: ipsec@ietf.org >Subject: [IPsec] Relating the two ESP-null documents > >Hi, > >As we near publication of the WESP and Heuristics drafts, we'd like to >make >sure that the WG consensus is clearly expressed in both documents. So we >propose to include the following note as a section in both documents. >Please >let us know if this works for you: > >-- begin text > >Applicability: Heuristic Traffic Inspection and Wrapped ESP >--- > >There are two ways to enable intermediate security devices to >distinguish >between encrypted and unencrypted ESP traffic: > >- The heuristics approach [heuristics I-D] has the intermediate node >inspect >the unchanged ESP traffic, to determine with extremely high probability >whether or not the traffic stream is encrypted. > >- The Wrapped ESP approach [WESP I-D], in contrast, requires the ESP >endpoints to be modified to support the new protocol. WESP allows the >intermediate node to distinguish encrypted and unencrypted traffic >deterministically, using a simpler implementation for the intermediate >node. > >Both approaches are being documented simultaneously by the IPsecME >Working >Group, with WESP being put on Standards Track while the heuristics >approach >is being published as an Informational RFC. While endpoints are being >modified to adopt WESP, we expect both approaches to coexist for years, >because the heuristic approach is needed to inspect traffic where at >least >one of the endpoints has not been modified. In other words, intermediate >nodes are expected to support both approaches in order to achieve good >security and performance during the transition period. > >-- end text > >[Note: both references are non-normative.] > >Currently both documents have direct or indirect references to one >another, >but they are not exactly in line with the consensus we have reached. In >both >cases the emphasis is on the two solutions competing with one another, >rather than complementing each other. > >Thanks, > Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Relating the two ESP-null documents
Works for me too! Cheers, Manav > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf Of Grewal, Ken > Sent: Tuesday, August 18, 2009 10.03 PM > To: Yaron Sheffer; ipsec@ietf.org > Subject: Re: [IPsec] Relating the two ESP-null documents > > Works for me! > > Thanks, > - Ken > > > >-Original Message- > >From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] > On Behalf > >Of Yaron Sheffer > >Sent: Tuesday, August 11, 2009 6:04 AM > >To: ipsec@ietf.org > >Subject: [IPsec] Relating the two ESP-null documents > > > >Hi, > > > >As we near publication of the WESP and Heuristics drafts, > we'd like to > >make > >sure that the WG consensus is clearly expressed in both > documents. So we > >propose to include the following note as a section in both documents. > >Please > >let us know if this works for you: > > > >-- begin text > > > >Applicability: Heuristic Traffic Inspection and Wrapped ESP > >--- > > > >There are two ways to enable intermediate security devices to > >distinguish > >between encrypted and unencrypted ESP traffic: > > > >- The heuristics approach [heuristics I-D] has the intermediate node > >inspect > >the unchanged ESP traffic, to determine with extremely high > probability > >whether or not the traffic stream is encrypted. > > > >- The Wrapped ESP approach [WESP I-D], in contrast, requires the ESP > >endpoints to be modified to support the new protocol. WESP allows the > >intermediate node to distinguish encrypted and unencrypted traffic > >deterministically, using a simpler implementation for the > intermediate > >node. > > > >Both approaches are being documented simultaneously by the IPsecME > >Working > >Group, with WESP being put on Standards Track while the heuristics > >approach > >is being published as an Informational RFC. While endpoints are being > >modified to adopt WESP, we expect both approaches to coexist > for years, > >because the heuristic approach is needed to inspect traffic where at > >least > >one of the endpoints has not been modified. In other words, > intermediate > >nodes are expected to support both approaches in order to > achieve good > >security and performance during the transition period. > > > >-- end text > > > >[Note: both references are non-normative.] > > > >Currently both documents have direct or indirect references to one > >another, > >but they are not exactly in line with the consensus we have > reached. In > >both > >cases the emphasis is on the two solutions competing with > one another, > >rather than complementing each other. > > > >Thanks, > > Yaron > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-01.txt
Hi, Tero, Thanks for the comments. Please check in lines: > Sean Shen writes: > > Hi, IPSECME WG, > > The 01 version of draft-ietf-ipsecme-aes-ctr-ike was uploaded. The > > modification addressed comments we received so far and also include > > some other editing. > > Major changes are as following: > > #4 > > Section 3.2 > > Added clear reference to rfc4302 and rfc4307 for integrity > requirement > > and algorithm choice. > > I do not think it is good idea to copy the table from RFC4307 > as it is likely to change in the future, so better would be > just to give reference to the document. > > On the other hand RFC4306 already says that "... > implementations MUST NOT negotiate NONE as the IKE integrity > protection algorithm ..." > (section 5. Security Considerations of RFC4306), thus AES-CTR > cannot be used without integrity algorithm in this context anyways. The point here is to say that integrity protection is needed with aes-ctr, not trying to specify which integrity algorithm to choose. rfc4306 already required integrity for ikev2 and we refered to 4306 here. The choice of integrity algorithm is up to rfc4307 or some update document, we just listed what rfc4307 chooses to make this document more rich of information. If you think the table gives misleading impression of only requiring these particular algorithms, we may add another sentence to hint that integrity algorithm requirement may change over time, please check 4307 and 4307's update, the following listed algorithm is just showing current 4307's requirement. > One thing that is not 100% clear from the draft is that > whether there is any padding in the encrypted payload. > RFC4306 says that encrypted part is padded up to the block > size of the cipher. In AES-CTR the block size is 1, thus that > does not require any padding. Normal ESP requires padding for > at least up to 4-byte boundary, regardless of the block size > of the cipher, thus even AES-CTR uses padding up to 4-byte > boundary. The IKEv2 SA does not require thus. > > I think it would be better to add text explictly saying this. > I.e. add text like this to the end of 2.3: > >... For this >reason, AES-CTR does not require the plaintext to be padded to a >multiple of the block size. For Encrypted Payload this means that >Padding field is always empty, and Pad Length field will always be >0. I don't agree with this. Specifying Padding field to be empty and Pad Length to be zero here is not proper, because rfc4306 requires that recipient MUST accept any lenght that results in proper alignment (section 3.14). Best, Sean ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
