[IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility
pasi.ero...@nokia.com writes: - A question: did the WG discuss the pros and cons of integrity protecting the WESP header? (This does make WESP more complex to implement, and currently the WESP header does not contain any data that would benefit from integrity protection in any way.) Thats is actually good question, as all of the data in the WESP header is verified by comparing it to data elsewhere (either in packet (Next Header) or data associated to SA (HdrLen, TrailerLen, flags)) already I do not think if protecting WESP header adds anything. I think that if we don't add it to ICV that could simplify implementations as the ICV calculations would be exactly same as they were before, so converting ESP - WESP would be simple, by just insertting new header and changing protocol number. - Section 2: The bits are defined LSB first, so bit 0 would be the least significant bit of the flags octet. This doesn't match the bit numbering in Figure 2 (where bit 0 is the most significant bit). However, the bit numbers are not really used anywhere, so I would just suggest deleting this sentence. I earlier proposed change that would add those bit numbers to the text, so bit positions would be also given in other place than in the picture. See my earlier message http://www.ietf.org/mail-archive/web/ipsec/current/msg04761.html - Section 2: the text about TrailerLen is a bit unclearly written -- the offset from the end of the packet to the last byte of the payload would be a negative number. I'd suggest phrasing this something like the The number of bytes following the payload data in the packet, in octets: i.e. the total length of TFC Padding (normally not present for unencrypted packets), ESP Trailer (Padding, Pad Length, Next Header), and ESP ICV. TFC Padding cannot be included in the TrailerLen as it can be too large to expressed in 8 bits. Actually reading the description it would indicate that the Padding, Pad Length and Next Header at the end of packet would be included in the TrailerLen, which would mean that even that might not be expressed in 8 bits in octects. I originally only assumed it includes the ICV field length, nothing else. That is the only thing needed by the intermediate device, as it can see pad length and padding from the packet and it can also skip the TFC padding in the same way recipient will do. With the current wording the TrailerLen would be different for each packet depending how many bytes of padding there is, which will mean that final recipient needs to do some extra calculations while verifying its length is correct (i.e it cannot simply compare the TrailerLen to fixed value based on the SA (12 for HMAC-SHA1 etc), but it needs to calculate Pad Length + ICV length + 2 + TFC Padding length and see that it matches the TralerLen. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Populating ID_DER_ASN1_DN
David Wierbowski writes: Thanks for the clarification. The text in 4301 makes sense. What I do not agree with is the text in 4945 that requires implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. I can agree with saying that implementations MUST be able to perform matching of the entire DN in ID to its entry in the SPD. It's the based on a bitwise comparison that I do not agree with. It should be up to the implementation to decide if it wants to do a bitwise match or use normal x.500 DN matching rules. I think one of the reasons the bitwise comparison is there, that some CA products have been known to issue certificates which are invalid by normal processing rules, for example they can use characters that are not allowed for PRINTABLE STRINGS (for example Latin1 characters for names). Depending on your matching engine it might be impossible to get those matching without bitwise comparison. I agree that it being MUST is not needed, it could be MAY or SHOULD. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPSECME Virtual Interim Meeting
Paul Hoffman writes: At 10:03 PM +0300 9/12/09, Yaron Sheffer wrote: The ipsecme WG will have a virtual interim WG meeting in about a month. We will have a conference call on Tuesday September 22, 15:00 GMT (18:00 Israel, 17:00 CET, 11:00 EDT, 8:00 PDT), for 2 hours. We are planning on the same format as the previous time: a VoIP conference bridge and posted slides. Technical details are available here: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls We are using the same TeamSpeak server as before, teamspeak.vpnc.org. I have turned on that server now so people can test it before the meeting. If you want to test your TeamSpeak client before the meeting, we will have a short test-run 24 hours before the meeting (that is, the same times as above, but on Monday, September 21). Now it is also good idea to make sure you find and enable the +20db gain / Mic Boost or similar setting of your windows sound card (Usually it is found in the Recording Control - microphone - Advanced - Advanced Controls for Microphone - Other Controls - Mic Boost / +20 DB gain / 1 (Yes sometimes it is just checkbox marked with 1)). If you do not have that activated your voice will be way too weak to be heard. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Query about SEq Number
HI, I have a query about the Sequence number in the ESP Header. If for any packet, the receiver finds the seq number as ZERO, what is the desired behavior..? Should this result in the anti-replay check failure..? Should this be treated as a corrupted packet..? Appreciate your inputs. Thanks Manish ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Query about SEq Number
On Fri, Sep 18, 2009 at 10:35:32AM -0500, Manish Aggarwal wrote: HI, I have a query about the Sequence number in the ESP Header. If for any packet, the receiver finds the seq number as ZERO, what is the desired behavior..? Should this result in the anti-replay check failure..? Should this be treated as a corrupted packet..? Solaris/OpenSolaris treats 0-on-the-wire as an anti-replay failure. Here's the code that does early-replay-checking (i.e. replay checking so obvious you don't need to crunch the authentication algorithm): http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/sadb.c#6156 And here's ESP calling, and bumping the appropriate bean-counters for early-replay drop: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/ipsecesp.c#1239 Hmmm, the comment here is quite old. We *do* check for collisions in early-replay, and have since AH/ESP support arrived in Solaris. Must've been a leftover from bringup... Hope this helps, Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Query about SEq Number
-Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan McDonald Sent: Friday, September 18, 2009 11:48 AM To: Manish Aggarwal Cc: ipsec@ietf.org Subject: Re: [IPsec] Query about SEq Number On Fri, Sep 18, 2009 at 10:35:32AM -0500, Manish Aggarwal wrote: HI, I have a query about the Sequence number in the ESP Header. If for any packet, the receiver finds the seq number as ZERO, what is the desired behavior..? Should this result in the anti-replay check failure..? Should this be treated as a corrupted packet..? Solaris/OpenSolaris treats 0-on-the-wire as an anti-replay failure. That would be appropriate if: - You have antireplay checking enabled - You are not doing Extended Sequence Numbers. In both of those cases, you can legitimately have a zero sequence number in the ESP header. Here's the code that does early-replay-checking (i.e. replay checking so obvious you don't need to crunch the authentication algorithm): http://src.opensolaris.org/source/xref/onnv/onnv- gate/usr/src/uts/common/inet/ip/sadb.c#6156 And here's ESP calling, and bumping the appropriate bean-counters for early-replay drop: http://src.opensolaris.org/source/xref/onnv/onnv- gate/usr/src/uts/common/inet/ip/ipsecesp.c#1239 Hmmm, the comment here is quite old. We *do* check for collisions in early-replay, and have since AH/ESP support arrived in Solaris. Must've been a leftover from bringup... Hope this helps, Dan ___ 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] Query about SEq Number
On Fri, Sep 18, 2009 at 09:34:26AM -0700, Scott Fluhrer (sfluhrer) wrote: -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan McDonald Sent: Friday, September 18, 2009 11:48 AM To: Manish Aggarwal Cc: ipsec@ietf.org Subject: Re: [IPsec] Query about SEq Number On Fri, Sep 18, 2009 at 10:35:32AM -0500, Manish Aggarwal wrote: HI, I have a query about the Sequence number in the ESP Header. If for any packet, the receiver finds the seq number as ZERO, what is the desired behavior..? Should this result in the anti-replay check failure..? Should this be treated as a corrupted packet..? Solaris/OpenSolaris treats 0-on-the-wire as an anti-replay failure. That would be appropriate if: - You have antireplay checking enabled If you look at the early-replay code, we do just this. - You are not doing Extended Sequence Numbers. In both of those cases, you can legitimately have a zero sequence number in the ESP header. We don't support 64-bit sequence numbers yet, but when we do, obviously any early-replay checks would have to be more careful about a 0 on the wire. Thanks for the helpful reminders, Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility
Hi Pasi, Many thanks for the great feedback. I will incorporate all these items as part of the WESP update during the next virtual interim meeting on Sept 22. Furthermore, I have opened multiple tickets to ensure these are tracked and resolved. Some comments inline...and others will result from the discussion during the interim meeting. Thanks, - Ken -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of pasi.ero...@nokia.com Sent: Thursday, September 17, 2009 6:05 AM To: ipsec@ietf.org Subject: [IPsec] AD review comments for draft-ietf-ipsecme-traffic- visibility I've now done my AD review for draft-ietf-ipsecme-traffic-visibility-08. I have two substantive comments, and a bunch of minor clarifications/nits. The substantive comments first: - A question: did the WG discuss the pros and cons of integrity protecting the WESP header? (This does make WESP more complex to implement, and currently the WESP header does not contain any data that would benefit from integrity protection in any way.) [Ken] This change was the result of a discussion on threats posed by 'malware', which could modify the WESP headers to obfuscate the payload from inspection by intermediate nodes such as IDS/IPS systems. The issue (ticket #104) was raised and closed some time back after lengthy discussions on the topic. http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/104 - IPv6 requires extension headers to be aligned on 8-octet boundaries, and I believe this requirement applies to ESP, too (see e.g. RFC 4303 Section 2.3, 2nd paragraph). All current ESP specs (all encryption algorithms, UDP encapsulation, etc.) meet the 8-octet alignment requirement -- but adding a new four-octet header there obviously breaks it. [Ken] Great point! Yes, this will need to be addressed and we do need to provide an extension of the header for alignment purposes in IPv6 usages. I have opened a new ticket (#109) to track this. Some minor clarifications/editorial nits: - The text currently uses using ESP-NULL [RFC2410] and unencrypted as synonyms. This was accurate before RFC4543, but is not any more. This needs some clarifying text somewhere (perhaps Section 1). - Section 1 needs a sentence or two motivating the existence of the E bit -- currently it comes as a surprise to the reader later. [Ken] I have reopened the related ticket #84 and we will generate / vet additional text to elaborate on the motivation. [Ken] I have captured the items below in a single new ticket (#110) as most are minor editorial changes. - Section 2/2.1: In Figures 1, 2, and 3, the bit numbers should be shifted one character to the right. [Ken] OK - Section 2: In some parts of the text, the last 8 bits of the WESP header are called Flags; in other parts, the last 5 bits are called Flags. I'd suggest changing e.g. Figure 2 so that last 5 bits are called Rsvd or something. [Ken] Agreed, using Rsvd is better than Flags. - Section 2: The bits are defined LSB first, so bit 0 would be the least significant bit of the flags octet. This doesn't match the bit numbering in Figure 2 (where bit 0 is the most significant bit). However, the bit numbers are not really used anywhere, so I would just suggest deleting this sentence. [Ken] Agree. We already have new text in the next rev of the draft using MSB, as Tero had separately raised this point. - Section 2: It would be helpful if the text explicitly said that HdrLen values less than 12 are invalid (and probably HdrLen values that are not multiple of 4 are invalid, and multiple of 8 for IPv6 case). [Ken] OK. - Section 2: the text about TrailerLen is a bit unclearly written -- the offset from the end of the packet to the last byte of the payload would be a negative number. I'd suggest phrasing this something like the The number of bytes following the payload data in the packet, in octets: i.e. the total length of TFC Padding (normally not present for unencrypted packets), ESP Trailer (Padding, Pad Length, Next Header), and ESP ICV. [Ken] Will discuss the scope of this, based on separate comment from Tero. - Section 2: the packet must be dropped - the packet MUST be dropped - The figures in 2.2.1 and 2.2.2 are very confusing, since they suggest WESP could be applied as a separate step after ESP processing (that was possible in some earlier versions of the draft, but not any more since ICV covers the WESP header). Since they don't really present much new compared to the figures in RFC 4303 Section 3.1.1/3.1.2, perhaps they could be omitted? Or if we want to keep them, they probably should show the packet before applying ESP? [Ken] Someone (do not recall who) had asked for these figures. But, I agree that it is misleading. So, propose we either remove these figures or change the 'before' diagrams to raw, instead of ESP. - Section 3: s/IPSec/IPsec/ - Section 4: this section is missing the allocation of SPI value 2 to indicate WESP from the SPI
