My emails to the ipsec list have been disappeared since Dec 3...
Tero Kivinen <kivinen@kivinen.iki.fi> Tue, 30 December 2003 17:52 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUHqnib070961; Tue, 30 Dec 2003 09:52:49 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28590 Tue, 30 Dec 2003 12:14:35 -0500 (EST)
X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@kivinen.iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <16369.46322.403323.356834@fireball.acr.fi>
Date: Tue, 30 Dec 2003 19:25:06 +0200
From: Tero Kivinen <kivinen@kivinen.iki.fi>
To: ipsec@lists.tislabs.com
CC: byfraser@cisco.com
Subject: My emails to the ipsec list have been disappeared since Dec 3...
X-Mailer: VM 7.04 under Emacs 20.7.1
Organization: Helsinki University of Technology
X-Edit-Time: 9 min
X-Total-Time: 14 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The ipsec mailing list seems to black hole all of my emails after I changed my email address (i.e I am sending mails using from address of kivinen@iki.fi, but I am subscribed to list as kivinen@kivinen.iki.fi). The bad thing is that I didn't get any feedback or notification that my mail didn't get through, I simply just noticed from the archives, that they are not there. Hopefully I managed to forge the headers of this mail to be so that it appears to be from the proper address... ---------------------------------------------------------------------- Message-ID: <16333.44549.395539.783836@fireball.acr.fi> Date: Wed, 3 Dec 2003 11:33:57 +0200 From: Tero Kivinen <kivinen@iki.fi> To: Darren Reed <avalon@caligula.anu.edu.au> Cc: ipsec@lists.tislabs.com Subject: comments on draft-ietf-ipsec-nat-t-ike-07 In-Reply-To: <200312030410.hB34AB3v023780@caligula.anu.edu.au> References: <200312030410.hB34AB3v023780@caligula.anu.edu.au> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology Darren Reed writes: > As a person who implements an "ike" proxy for IP, I was reading > through the NAT-T draft and noticed a few glaring problems... > > First, in the exchange of data, the current draft describes > UDP traffic like this (abbreviated): > I(500,500)-> > <-R(500,X) > I(500,500)-> > <-R(500,X) > This doesn't bode well for sane NAT setup as it requires two > NAT sessions to be maintained (well at least for ipfilter :): No, it does not require. The initiator sends packet UDP(500, 500). The NAT will map that to UDP(X, 500). The responder only sees the UDP(X, 500). It will reply with the packet UDP(500, X), the NAT will map that to UDP(500, 500), and the initiator will only see that. Same goes with the port 4500, execpt the NAT will of course create new mapping for the new source, port thus UDP(4500, Y). > one for the outgoing packets and another for the incoming. > The real problem here is that they're not the same, when they > should be as it's all the same "session". The problem is that > the firewall/NAT device doesn't know that the responder is > going to use source port X and said device would appear to > have no way to know it should, when compared to a non-NAT-D > IKE conversation. The firewall/NAT device is the one who did allocate that X, thus it do knows. The responder always replies back with packets with source and destination ports reversed. > Second, to complicate matters, it deson't seem possible to > distinguish a NAT-D capable host from those that aren't at > the outset of the session. The inclusion of the NAT-D section > in the initial packet would help the above problems but is > that problematic for other reasons? There will be a Vendor-ID payload in the first 2 packets, so it is possible for the firewall/NAT to detect whether the IPsec implementations support NAT-T. There MUST NOT be any reason for the firewall/NAT box to find that information out, as the protocol should work as long as the firewall/NAT does NOT do anything special for the port 4500. > Third, the same problem with port numbers and IKE traffic > has been made with the traffic on port 4500. Is there any > advantage to using (4500,4500) on the first packet? Yes. The firewall/NAT boxes does all kind of wierd things with port 500, that will break the NAT-T. So we had to pick another port number that hopefully WILL NOT have any special handling in the NAT boxes. > Or why isn't Y in that packet ? Personally, I see no advantage, > security or otherwise, to fixing the source port. Source port is fixed, the destination port is the one that NAT mapped the original source port to. > In the > historical case of DNS, it was a way to distinguish server > to server communication from regular client to server talk. > Here we've got client to server communication that has no > security benefit or otherwise from being on source port 4500. > Any benefit you get from being able to configure a rule for > both ports being 4500 on one side is lost completely with the > replies coming from ports unknown. For the initiator the packets will always come as 500,500 or 4500,4500, for the responder the source port might be different as NAT mapped the source port to something different, thus it must reply back so that port numbers are reveresed, meaning that the source port will be 500 or 4500 and destination port will be the one mapped by NAT. (Here I assume that initiator is behind NAT and responder is not). > Fourth, wouldn't it be appropriate to specifically say, in > the draft, that NAT devices MUST NOT alter the NAT-OAi or > NAT-OAr sections? If NAT devices can modify those encrypted and authenticated packets, then I think there is something much more seriously wrong in the IKEv1 :-) I.e as those packets are encrypted and authenticated, NAT does not have any way to modify those sections. > Fifth, is this draft applicable to both IKEv1 and IKEv1? Only IKEv1, as you say :-) > It doens't say but whereas IKEv2 appears to make special > provisions for this protocol to work, IKEv1 doesn't? IKEv2 will have the same mechanisms built in to the protocol from the beginning, i.e the specification will be inside the draft-ietf-ipsec-ikev2-* draft, not using this draft. This draft will only describe the IKEv1 case. > I suppose the *REAL* problem with this entire draft is that > there isn't something in the IETF protocol suite equivalent > to UPNP (www.upnp.org) for the IKE/IPsec device to become > aware of the NAT device or talk to it, or should I not even > go there ? O:-) The requirements for the NAT-T protocol was that it must work with most currently deployed NATs, i.e we cannot require any special protocols in the NATs, and we must have work arounds for all wierd things in NATs where they try to get some limited IPsec passthrough themselfs (breaking the NAT-T at the same time). > Just one last question, if there are three or more NAT devices > in the chain betweem the two endpoints, does this draft expect > an IKE conversation & IPsec to succeed for AH ? AH was dropped out from the specification completely. It currenly only support ESP. AH and NATs really don't match (i.e what is point of protecting the ip-addresses if NAT is going to change them). Tunnel mode ESP protects same things and it works. -- kivinen@iki.fi ---------------------------------------------------------------------- Message-ID: <16352.7443.329362.858769@fireball.acr.fi> Date: Wed, 17 Dec 2003 11:08:35 +0200 From: Tero Kivinen <kivinen@iki.fi> To: Michael Richardson <mcr@sandelman.ottawa.on.ca> Cc: ipsec@lists.tislabs.com Subject: IANA template document In-Reply-To: <29917.1071618241@marajade.sandelman.ottawa.on.ca> References: <29917.1071618241@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 21 min X-Total-Time: 33 min Michael Richardson writes: > IKEv2 Payload Types > IKEv2 Transform Types How about the protocol-id inside the Proposal Substructure? It is currently only defined in the draft, there is no table, and it have only 3 values (0 = IKE, 1 = ESP, 2 = AH). Are there going to be new numbers for that later? Should we include that too just in case? I.e IKEv2 Proposal Substructure Protocol-IDs > IKEv2 Encryption Transform Values > IKEv2 Pseudo-ramdom Function Transform Values > IKEv2 Integrity Algorithm Transform Values > IKEv2 Diffie-Hellman, ECP and EC2N Transform Values > IKEv2 Extended Sequence Numbers Transform Values These are actually Transform IDs not Transform Values, i.e IKEv2 Encryption Algorithm Transform IDs IKEv2 Pseudo-random Function Transform IDs IKEv2 Integrity Algorithm Transform IDs IKEv2 Diffie-Hellman Group Transform IDs IKEv2 Extended Sequence Numbers Transform IDs Another thing I noticed is that the section 3.4 Key Exchange Payload should have pointer back to the section 3.3.2 Transform Substructure / Transform Type 4 (Diffie-Hellman Group) Transform IDs for the DH Group #. It currently does not have that pointer. > IKEv2 Identification Types IKEv2 Identification Payload ID Types > IKEv2 Certification Payload Format IKEv2 Certificate Encodings > IKEv2 Authentication Method > IKEv2 Notification Payload Type How about the Notify Payload S_Protocol_IDs? Again This is only defined to have 3 values (1 = IKE_SA, 2 = ESP, 3 = ESP, note different values than proposal substructure protocol-ID!). Should we include this too? I.e IKEv2 Notify Payload / Security Protocol ID (For some reason the S_Protocol_ID / SECURITY_PROTOCOL_ID is using underscores, instead of dashes, some other places use Protocol-Id instead). > IKEv2 IPComp Transform IDs > IKEv2 Security Protocol ID Which protocol id this is? The Proposal, Notify or Delete payload Security Protocol ID? Because of its location I assume it is the Delete payload S_PROTOCOL_ID (again with underscores and capital letters). Numbers of the delete payload security payload id seems to match the Notify Payload security payload id numbers... > IKEv2 Traffic Selector Types > IKEv2 Configuration request types IKEv2 Configuration Payload CFG Type or something like that. It would be good to try to match the exactly same texts we have in the IKEv2 document. > IKEv2 Configuration attribute types -- kivinen@iki.fi ---------------------------------------------------------------------- Message-ID: <16352.8503.137520.638861@fireball.acr.fi> Date: Wed, 17 Dec 2003 11:26:15 +0200 From: Tero Kivinen <kivinen@iki.fi> To: charliek@microsoft.com CC: ipsec@lists.tislabs.com Subject: Some typos in the ikev2 draft X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 17 min X-Total-Time: 17 min Here are some typos and nits that could be fixed when you are making the next version of the ikev2 document: 1) Appendix A, 4) uses CHILD-SA instead if CHILD_SA. 2) There seems to be several ways to type in the field names. The proposal substructure uses "Protocol-Id", the Transform Substructure uses "Transform ID", the Notify and Delete Payload have "S_Protocol_ID" in the figure and "SECURITY_PROTOCOL_ID" in the description, and finally the Traffic Selector payload uses "Protocol_ID". Most of the other places use field names inside the payloads with spaces, and capitalize only first letters ("Next Payload"). I think we should change those Protocol-ID / Protocol-Id / S_Protocol_ID / SECURITY_PROTOCOL_ID formats to "Protocol ID" and also fix the other field names using underscore (Start_Port / End_Port). 3) Also the section 3.3 refers to the SECURITY_PROTOCOL_ID while the proposal substructure have "Protocol-Id". 4) Also the Protocol IDs used in the proposal substructure and in the notify and delete payloads are not same. Is this intentional? If so we should have warning saying so. 5) INVALID_SYNTAX and INVALID_MESSAGE_ID used "MESSAGE_ID" instead of "Message ID". 6) The 3.4 Key Exchange Payload should have pointer back to the section 3.3.2 Transform Substructure / Transform Type 4 (Diffie-Hellman Group) Transform IDs for the DH Group #. PS. When are you planning to make the next version? -- kivinen@iki.fi ---------------------------------------------------------------------- Message-ID: <16368.46578.80635.927942@fireball.acr.fi> Date: Tue, 30 Dec 2003 01:17:06 +0200 From: Tero Kivinen <kivinen@iki.fi> To: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com> Cc: "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com> Subject: Re: I-D ACTION:draft-ietf-ipsec-esp-ah-algorithms-00.txt In-Reply-To: <62173B970AE0A044AED8723C3BCF2381037F3334@ma19exm01.e6.bcs.mot.com> References: <62173B970AE0A044AED8723C3BCF2381037F3334@ma19exm01.e6.bcs.mot.com> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 5 min X-Total-Time: 5 min Eastlake III Donald-LDE008 writes: > I believe that this draft should also have a table for authenticated > encryption algorithms for ESPv3 and should list AES-CCM as at least > MAY. I see no reason to list one algorithm as MAY in the document. This is the algorithm requirements document. MAY is not a requirement. All the algoritms not listed in this document are MAYs. Also I do not see any point of repeating all the algoritms from the IANA registry here, and say that they are MAYs. Perhaps we should add text in the document explicitly saying this? I think that also the HMAC-MD5-96 should be removed as it is also only MAY. Also I do not think AES-CCM is ready for the SHOULD status yet, we need some real world implementations now. -- kivinen@iki.fi ---------------------------------------------------------------------- Message-ID: <16369.39479.663946.756843@fireball.acr.fi> Date: Tue, 30 Dec 2003 17:31:03 +0200 From: Tero Kivinen <kivinen@iki.fi> To: Pasi.Eronen@nokia.com Cc: <hugo@ee.technion.ac.il>, <ipsec@lists.tislabs.com> Subject: RE: Clarification of EAP authentication in IKEv2? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612234D@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A612234D@esebe023.ntc.nokia.com> X-Mailer: VM 7.04 under Emacs 20.7.1 Organization: Helsinki University of Technology X-Edit-Time: 10 min X-Total-Time: 10 min Pasi.Eronen@nokia.com writes: > An initiator indicates a desire to use extended > authentication by leaving out the AUTH payload from message > 3. By including an IDi payload but not an AUTH payload, the > initiator has declared an identity but has not proven it. If > the responder is willing to use an extended authentication > method, it will place an EAP payload in message 4 and defer > sending SAr2, TSi, and TSr until initiator authentication is > complete in a subsequent IKE_AUTH exchange. The responder R now have 3 options how to authenticate himself to initiator I: 1) Use signatures to authenticate R to I. 2) Use pre-shared key to authenticate R to I. 3) Use EAP exchange which provides mutual authentication and provides shared key between R and I. All other options are unsafe, and MUST NOT be used (i.e use EAP exchange without mutual authentication and not using signatures or pre-shared keys). For cases 1 and 2 the responder will include the first AUTH payload in the message 4 (generated as normally done for signatures or for pre-shared keys). For case 3, the AUTH payloads are postponed until the EAP exchange is done, and the shared key is from it is available. Your text is same, but I think the cases should be listed first, and then explain them later. -- kivinen@iki.fi
- My emails to the ipsec list have been disappeared… Tero Kivinen