Re: [IPsec] IANA port number assignment name for IKEv2
On Sat, Oct 09, 2010 at 12:56:04PM -0400, micah anderson wrote: SNIP! RFC2409 has been obsoleted by 4306 which was then obsoleted by 5996. My understanding of obsoleted rfcs means that what they contain is no longer valid. RFC 2409 used port 500 for ISAKMP, but RFC 5996 has overtaken that port by the IKEv2 protocol. If we move forwards with port 500 named after the obsolete RFC 2409 ISAKMP, but use it for IKEv2, then we are doing a disservice to people trying to understand what is going on. IKEv1 was ISAKMP+oakley+skeme, and IKEv2 is none of that. From what I can tell, IKEv2 has nothing to do with ISAKMP, except for the lineage as described above. So if you want to be a pedant, let's call 500 (and 4500) what they really are: 500/udp Internet Key Exchange (IKE), versions 1 and 2 4500/udp NAT-Traversal for IPsec and IKE Here are the entries in Solaris's /etc/services, e.g.: ike 500/udp ike # Internet Key Exchange ipsec-nat-t 4500/udp# IPsec NAT-Traversal Why is this a big deal? Are you just wanting to make sure IANA reflects reality? Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Question about AUTH payload
On Thu, Jul 01, 2010 at 01:02:20PM -0500, Joy Latten wrote: SNIP! I am thinking it can be concluded that responder computed MACedIDForR with 1's in the RESERVED field. That seems valid (though clearly the implementation who sends 1s is violating Postel's Law, but you did say it's a TAHI test...). Initiator needs to compute MACedIDForR to verify the MACedIDForR he received from responder. Should he use the IDr payload responder sent with 1's in RESERVED field? Yes, that's how I interpreted it. You can't rewrite bits that are fed into an off-the-wire authentication calculation. Or does ignoring content of RESERVED field mean initiator can safely assume/build the IDr payload using 0's for RESERVED field when he computes MACedIDForR? Of course in this case the authentication will fail... would that be expected behaviour? Postel's Law (Be conservative in what you send, be liberal in what you receive.) would suggest you compute the authentication with the EXACT contents of what was on the wire. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Invalid transform type in an SA payload - which error?
While going over some error cases, we wondered if some miscreant sends us a transform of type PRF in a CHILD_SA or AUTH exchange where the SA payload is clearly intended for a Child SA (e.g. ESP or AH)? Would INVALID_SYNTAX or NO_PROPOSAL_CHOSEN work better here? Thanks, Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Multiple IPsec proposals, same SPI?
Consider the example in section 3.3 of IKEv2bis, which I've edited for brevity: SA Payload | +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, | |7 transforms, SPI = 0x052357bb ) (either way for ESN, three CBC ciphers, two hashes) +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, |4 transforms, SPI = 0x35a1d6f2 ) (either way for ESN, two GCM ciphers) the example shows two distinct SPI values. Is it *required* that the SPI values be different? For example, PF_KEY has SADB_GETSPI which merely reserves an inbound SPI value, without ANY other properties attached. IN theory, given the above example, I could instead issue: SA Payload | +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, | |7 transforms, SPI = 0x052357bb ) (either way for ESN, three CBC ciphers, two hashes) +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, |4 transforms, SPI = 0x052357bb ) (either way for ESN, two GCM ciphers) since I merely did a GETSPI which reserved 0x052357bb. Thanks, Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #173 - Trigger packets should not be required
Am reading this right? On Fri, Feb 19, 2010 at 08:22:51AM -0800, Paul Hoffman wrote: At 1:10 PM +0200 2/19/10, Tero Kivinen wrote: Yoav Nir writes: Hi all. There are only three issues this time, because this is the last batch. Issue #173 - Trigger packets should not be required === In a few places in the new section 2.23.1 in IKEv2bis, it says that one must have a trigger packet when starting negotiation. This assumption should be removed so as not to cause new requirements in IKEv2bis: there is no requirement for trigger packets in RFC 4306 or in the rest of IKEv2bis. - When the client starts creating the IKEv2 SA and Child SA for sending traffic to the server, it has a triggering packet with source IP address of IP1, and a destination IP address of IPN2 should be changed to ...it may have a triggering packet This change is wrong. Tero -- why precisely is may have a triggering packet wrong? The change is to say, may have a triggering packet, right? If I understand that, then what Tero says: If client starts creating IKEv2 SA for sending traffic, it will have trigger packet. If it creates IKEv2 SA for some other reason (i.e not because of trigger packet, but because of autostart rule or similar), then it does not have triggering packet. AND what Paul says: We disagree. If a client starts creating an IKEv2SA for sending traffic, it may do that because it knows it will have packets in the future, but does not have them when it sets up the SA. An autostart rule that is based on *knowing* that something will come in the future is still creating IKEv2 SA for sending traffic. are both true. If there's disagreement, it's only because you two are tassling over what constitutes creating an IKEv2 SA for sending traffic. Sure an IKEv2 SA can be used for sending traffic, but creating one doesn't have to be the result of an outbound packet that needs AH or ESP protection. Both of you acknowledge, I believe, that creating an IKEv2 SA can occur without a triggering packet (whether it's by some autostart rule, or some explicit administrator action). Am I missing something else? Ahh, I think I am. After reviewing Tero's note: All of that paragraph is for the case where you do have packet. It does not cover other cases. - The same change is made in the third bullet of the client list near the end of the section. This is the one that needs to be changed, as that third bullet is not only specific to triggering packet case, it is in the generic processing section, i.e. that bullet should be changed to: - If SA is created because of the data packet, then the first TSi and TSr traffic selectors SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request. So Tero -- you agree that an IKEv2 SA can be created w/o a triggering packet, but the changes need to be localized to only certain portions of 4301bis, while the other portions of text only apply when we KNOW a triggering packet would be present? Just checking, Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #173: Trigger packets should not be required
On Tue, Feb 02, 2010 at 02:49:11PM -0800, Paul Hoffman wrote: In a few places in the new section 2.23.1 in IKEv2bis, it says that one must have a trigger packet when starting negotiation. This assumption should be removed so as not to cause new requirements in IKEv2bis: there is no requirement for trigger packets in RFC 4306 or in the rest of IKEv2bis. BTW, this change makes a path to no-child-SA AUTH exchanges simpler. It's much simpler to have a no-child-SA creation of an IKE SA when you aren't initiating in the service of a triggering packet. - When the client starts creating the IKEv2 SA and Child SA for sending traffic to the server, it has a triggering packet with source IP address of IP1, and a destination IP address of IPN2 should be changed to ...it may have a triggering packet This new text is fine. - The first traffic selector of TSi and TSr SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request should be changed to ...SHOULD have very specific traffic selectors including protocol and port numbers, such as from the packet As is this new text. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Replay Protection
On Tue, Feb 02, 2010 at 06:15:40AM +0530, Venkatesh Sriram wrote: Hi, Most IETF documents state that replay protection is not provided with manual keying. I wanted to understand the reason for the same. Is it because with manual keying there is no way to negotiate the sequence numbers and thus provision for replay protection is not supported? You *could* enforce replay protection on manually added SAs, but with the restrictions that: - Both SAs must be kept in sync at all times. Reboots, or other expiration events, will not be able to kick any key-management-protocol (e.g. IKE) in the pants to get new SAs. - SAs MUST be unicast. There's no easy-to-secure way to share replay state across a multi-receiver or multi-sender SA. Programming interfaces to the SADB (like PF_KEY) or manual-keying programs (like setkey(8) on BSD or ipseckey(1M) on OpenSolaris) might be able to allow a manually-keyed SA with replay protection, but without the above operational restrictions, things would break down quickly. This is why most manual key programs do not enable replay protection on an SA by default. Hope this helps, Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] No UDP encapsulation with IKEv2 over port 4500?
I read this sentence in IKEv2bis... If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. ... and thought of my own implementation. The background reading is here: http://blogs.sun.com/danmcd/entry/detangling_ipsec_nat_traversal_and Today, my implementation marks a port (a socket option to be precise) as a NAT-Traversal port. Traffic to this port that has the zero-SPI gets the zero-SPI stripped and the datagram passed to UDP like any other UDP datagram. If the SPI is non-zero, the UDP portion is stripped, and the packet is passed to ESP for lookup. If there's no SA, the packet is dropped like any other ESP packet with a bad SPI. The text above suggests that if I'm to build IKEv2 properly, I need to not drop these bad-SPI ESP-in-UDP packets (local-port == 4500), but instead pass them up as a UDP datagram without any strippage. Am I understanding this correctly? Or does the text need some more rewhacking? I'm not sure what problem 4500-with-no-encapsulation solves. If you use port 4500, you're most likely going to be doing ESP-in-UDP anyway, and will need the zero-SPI for IKE traffic anyway. And what if you hit that N-in-2^32 chance (where N is the number of inbound SAs) where the high 32-bits of the IKE SPI value is the same as some IPsec SA? Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] What problem are we REALLY trying to solve? (was Traffic visibility)
SNIP! Transport policies for within an organization that want to enable intermediary inspection of ESP-NULL non-heurisitically. Organization has a mix of version of systems. At this point I need more details. Specifically, why does an organization need to inspect ESP-NULL packets? I can think of two good reasons off the top of my head: * To appropriately schedule or forward a packet according to latency, or any other number of diffserv properties. - Deep-packet inspection for content or other beyond-the-headers processing. I've marked the first item with *, and the second with -. Items marked with * merely requires flow classification. In IPv6 we have a flow id already, and there are rumblings of a hop-by-hop IPv4 option to do the same thing here: http://tools.ietf.org/html/draft-dreibholz-ipv4-flowlabel-11 (Heck, it's even 20 bits!) Items marked with - require that the payload be in the clear, or (by some miracle) the inspecting entity has the cryptographic keys. Items marked with * can use flow labels. Yes it's a host software change, but quite frankly so is WESP. WESP doesn't do anything in this case an alternate mechanism cannot do. Items marked with - will benefit greatly from WESP IF (and only if) you believe heuristics to be untenable, but encrypted WESP support won't help here at all. Furthemore, a working flow label deployment and flow labelling policy could make what were heuristics into completely deterministic processing. There's vague talk about deployability and future directions. Please show me some concrete examples supporting WESP with encrypted packet support. I suspect such examples will most likely either require the whole packet text (i.e. marked with -) or just enough data to identify a flow (i.e. marked with *). Thanks, Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
On Tue, Jan 05, 2010 at 02:52:55PM +0200, Tero Kivinen wrote: SNIP! If we really want to make WESP as specified in the charter, it would be much better to make it so it can be added incrementally to the ESP processing, i.e. just like UDP encapsulation for NAT-traversal can be do. This would mean that the WESP processing could be applied after the normal ESP processing, and WESP would simply add extra header to the beginning, and nothing else. The current draft already makes sure all the fields in the WESP header are verified by the IPsec recipient thus there is really no need to add ICV to cover them (if extensions are added then ICV needs cover them, which makes it impossible to implement WESP as incremental change to ESP). Yes -- this would allow WESP to be an attribute one adds to an ESP SA. Not unlike NAT-Traversal, it could be negotiated by IKE. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Labelled IPsec
On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote: But this is not a reason to oppose labelled IPsec. It's a reason to want an extended IP packet labelling standard. Why spend the time and effort to develop two specifications (not to mention the actual implementations) when one IP option based labeling spec could solve both use cases at the same time? Because sometimes you want to put sensitive traffic on public networks, without the overhead of tunnel mode (until we can get the world to go beyond 1500-byte datagrams, overhead IS a problem). IPsec SAs are perfect repositories for sensitivity information. And you can continue to use explicit labelling either to transit label-reading routers if you must. I'm not exactly sure how you envision this working, but for the sake of argument lets say that for the certificate derived security labels node A sends a cert to node B as part of the IKE negotiation which node B then uses to derive a security label for the SA matching node A's traffic (indirectly labeling node A's traffic as it is received). This is an interesting scenario because it doesn't actually involve any security labels being transfered over the network, either via IKE or AH/ESP; in fact, if you implement it correctly you could probably achieve this today using a standard IPsec implementation on node A (only node B and its IPsec implementation need to be label aware). I hasn't thought about this too much until just now, but I would almost consider this case to be a method of fallback labeling; instead of deriving the security label from an IP address you derive it from an authentication token. You could have PAD entries that set labels. We do that today in OpenSolaris. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Labelled IPsec
On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote: SNIP! I believe they are becoming more mainstream. For example, SELinux and Simplified Mandatory Access Control (SMACK) in Linux Operating System and Mandatory Integrity Control in Windows Vista. You forgot OpenSolaris Trusted Extensions (and their brand-new IPsec support): http://hub.opensolaris.org/bin/view/Project+txipsec/ The page needs an update, because the bits are now available for use. The bigger point being missed by this thread, I think, is that it seems that any work in multi-level security needs to deal with successful interoperability. If it doesn't, there's little point in documenting a single-platform solution as part of a working group's output. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New issue: INTERNAL_ADDRESS_FAILURE error and how to continue.
On Tue, Dec 01, 2009 at 03:24:18PM +0200, Tero Kivinen wrote: The section 1.2 says that if we get INTERNAL_ADDRESS_FAILURE then the IKE SA stays up, but the child SA is not created. It does not say anything what should happen on the initiator if it actually did require address by policy. Interactions like these show the hazards in integrating address configuration into a key exchange protocol. But since we've already thrown in with this since the days of MODE-CFG in IKEv1... Perhaps adding following paragraph to the end of 3.15.4 would help: -- If the initiator does not receive the IP address(es) required by its policy, it MAY keep the IKE SA up and retry the configuration payload (as separate INFORMATIONAL exchange) after suitable timeout, or it MAY also tear down the IKE SA (by sending DELETE payload inside separate INFORMATIONAL exchange) and retry IKE SA from the beginning after some longer timeout. The timeout should not be too short (especially if the IKE SA is started from the beginning), as these error situations will only be fixed when more entries are returned to the address pool of the responder, thus it will not be fixed in seconds, but more likely it takes several minutes. This is definitely the right idea. And the responder should already be able to react to either initiator choice (try with existing IKE SA, or deal with new IKE SA). Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #122: Integrity proposals with combined algorithms
On Mon, Nov 23, 2009 at 04:32:43PM -0800, Paul Hoffman wrote: The second sentence seems wrong. Proposed rewording: For example, [AEAD] specifies additional formats based on authenticated encryption, in which the integrity algorithm is an inherent part of the combined algorithm; in this case, the integrity algorithm is specified as none. Yes, this is much clearer, given we have a well-defined none value for integrity. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
On Mon, Nov 23, 2009 at 08:37:32PM -0500, Dan McDonald wrote: SNIP! The warning and URL is the critical part. are the critical part, - uggh, mustn't press Send so quickly. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] How long does an IKEv1 session take to complete?
On Wed, Nov 18, 2009 at 10:00:22AM -0800, Gregory Lebovitz wrote: Additionally it will depend on the round trip time across the network between the two peers. Ahh, of course. Vendors who are selling network boxes that can do a large number of simultaneous IKE negotiations tend to care more about simultaneous IKE SA negotiations per second than they do the actual negotiation time of any one single negotiation. Yes, the throughput vs. latency issues. A user might care about his/her latency (0-to-IPsec times), but a server vendor (not just a VPN box, BTW -- imagine the IPsec-protected server) might care a lot more about aggregate P1s/second. Dan ___ 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
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] IV in ESP packets for AES-CBC and AES-CTR methods
On Mon, May 11, 2009 at 08:22:05PM +0530, ss murthy nittala wrote: The following sentence present in RFC 3602 creates some doubts whether IV in each packet is mandatory or not? Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit. Nothing vague about it at all! In fact, this paragraph strengthens the argument Tero made in his note: Using the previous cipher-text block is a Bad Idea (TM). An IP datagram is self-contained, and the IV is mandatory because you can't start a CBC decryption without one, and there's no other way to get an IV. Dan ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
