Re: [IPsec] Nudge on discussion of WG work item: IKE over TCP
Hi,
a few remarks regarding interaction with NAT traversal.
1. In case there's a NAT in between and IKE_AUTH is done over TCP,
there's no event of switching to UDP ports 4500 (which usually takes
place in IKE_AUTH).
a) Which ports should use responder if it wants itself to initiate new
Exchange over UDP
or just wants to send a UDP encapsulated ESP packet to initiator? I
see one possibility -
responder must wait untill Initiator initiates any subsequent
Exchange over UDP 4500
or sends some UDP encapsulated traffic - only after that responder
could learn
the ports NAT is allocated for this mapping. But in general this may
never happen -
IKE SA could be established with no triggering packet from initiator
("Connect" button).
b) In case initiator is behind NAT it seems that responder can't use
ephemeral TCP
for any exchange it initiates, can it? And it can't initiate over
UDP untill
get learned the ports NAT has allocated (see clause above).
2. Draft says that retransissions could be done over different transport.
In case IKE_SA_INIT request is first sent over UDP and then
retransmitted
over TCP, what about NAT_DETECTION_SOURCE_IP content? According to
RFC5996 the retransmitted message MUST be identical to original,
but in this case source port of TCP session will most likely be
different
from port original message was sent from, that will lead
to erroneous NAT detection.
3. Related to above: RFC5996 allows to make IKE_SA_INIT request directly to
UDP 4500
instead of 500. The draft says that TCP transport is using port 500.
Because only one NAT_DETECTION_DESTINATION_IP can be included
In IKE_SA_INIT, we again face the problem of erroneous NAT detection.
4. If ports are included in COOKIE calculation, retransmissions of
IKE_SA_INIT containing COOKIE over different transport will be rejected.
Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt
I updated the draft-kivinen-ipsecme-oob-pubkey document, the new version includes some examples in the appendix, including the actual bits on the wire examples. One thing that needs to be decided before this document is ready: "What shall we do with the old "Raw RSA Key" format?" The current draft keeps it, and RECOMMENDs this new format for all types of raw keys, and does the negotiation using the standard IKEv2 CERTREQ payloads. This means there is two ways of doing exactly same thing, i.e. sending Raw RSA keys in IKEv2. Another option would be to change this document to be Standard track document, mark it as Updating 5996, and say that using old "Raw RSA Key" format is NOT RECOMMENDED. This would mean there is only one way of sending Raw RSA keys keys in IKEv2, i.e. the new way. Third option would say that this new format is only used for non-RSA keys, and for Raw RSA keys, you always MUST use the old format. I do not like this last option as it would require minimal implementations to implement both formats, as with both of the above options the minimal implementation can just decide that it only supports this one format and uses it for everything. I would like to get feedback from the WG, which way should we go forward? -- From: internet-dra...@ietf.org Subject: New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt Date: Tue, 16 Oct 2012 05:40:09 -0700 A new version of I-D, draft-kivinen-ipsecme-oob-pubkey-01.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Filename:draft-kivinen-ipsecme-oob-pubkey Revision:01 Title: More Raw Public Keys for IKEv2 Creation date: 2012-10-16 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-oob-pubkey-01.txt Status: http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey Htmlized:http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-oob-pubkey-01 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol currently only supports raw RSA keys. In some environments it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This documents adds support for other types of raw public keys to IKEv2. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Nudge on discussion of WG work item: IKE over TCP
Yoav Nir writes: > True. But do you think it's a common case, where the responder is > behind a filter that drops TCP port 500, but that responder knows of > a different port that is open? I suppose the responder could be > behind some NAT device with the ability to map a forwarded port on > the NAT device. I guess this makes sense. But then you have the > initiator opening a connection to a random port. That has a far > greater chance of getting filtered on the initiator side (firewalls > tend to drop what they don't recognize). If initiator is behind NAT and uses some of those protocols to talk to the NAT / FW and request a TCP port that will get forwarded to it then this sending that port number inside the IKE notify payload would be useful, in case the responder ever needs to reconnect back to him. Also quite often firewalls have been set up so that all incoming connections not explicitly allowed are forbidden, but all outgoing connections not expiicitly forbidden are allowed. Now when the initiator sets up the TCP listener port by talking to the NAT / FW, then responder can connect to that port if needed, and responders NAT / FW most likely will allow responder to connect to that port without any special configuration. > At least in our firewall, FTP got special treatment - the control > connection is monitored to recognize and allow the ports that are > used by the data connections, but I don't think we can expect the > firewall makers repeat this effort for IKE with random ports. This is because firewalls try to do this without the help of the FTP client / server. There are now protocols which allows client / servers to connect to the NAT / FW and ask for this kind of services, thus there is no need for NAT / FW to look inside the data packets and find out the ports. > > Should the initiator also send IKE_TCP_SUPPORTED to the responder? The > > initiator/responder roles could switch around at rekey, and it would > > be useful to the initial responder (now initiator) whether or not it > > can or should just start with TCP. Although it could deduce this from > > having received a connection on TCP in the previous exchange. I'm not > > sure on this one. > > I guess, but rekey doesn't require TCP, as it doesn't have the > IKE_AUTH exchange. It may be useful so that next time the original > responder can begin the Initial exchange with TCP. You are assuming that only reason to use TCP is because the IKE_AUTH packet is so big it gets fragmented. There has been also some comments that using TCP also helps going through NAT / FW boxes, in which case TCP is required to do any exchanges. I have not read the latest version, it is on my todo list, I will get back with more specific comments when I have time to read it. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Nudge on discussion of WG work item: IKE over TCP
On Oct 16, 2012, at 5:14 AM, Paul Wouters wrote: > On Mon, 15 Oct 2012, Paul Hoffman wrote: > >> Greetings again. draft-ietf-ipsecme-ike-tcp-00.txt has been out for over a >> month and has received no discussion. Please review this short draft and >> comment on the mailing list. > > Thanks for the reminder. > > I've read the draft and discussed it in Vancouver as well. I'm in favour > of adopting it. Well, you got it. It's already a working group draft. > I know no one wants to define this for IKEv1, but I'd still prefer to > keep this in sync between IKEv1 and IKEv2. I agree, and there's nothing stopping you (or me) from implementing this for IKEv1, but the group has spoken. See similar discussions about Brainpool curves. > I don't neccessarilly agree with the 1.1 non-goals. While I understand > this is not done primarily to avoid administrative filters, I see no > reason why to go out of our way to make it easy to filter IKE/IPsec. > If IKE could signal a TCP port along with the IKE_TCP_SUPPORTED payload > this would allow people so more freedom with running on different ports, > or even kickstarting IKE over another protocol (instant message, > whatever). I think the two octets are well spent for this. True. But do you think it's a common case, where the responder is behind a filter that drops TCP port 500, but that responder knows of a different port that is open? I suppose the responder could be behind some NAT device with the ability to map a forwarded port on the NAT device. I guess this makes sense. But then you have the initiator opening a connection to a random port. That has a far greater chance of getting filtered on the initiator side (firewalls tend to drop what they don't recognize). At least in our firewall, FTP got special treatment - the control connection is monitored to recognize and allow the ports that are used by the data connections, but I don't think we can expect the firewall makers repeat this effort for IKE with random ports. > Should the initiator also send IKE_TCP_SUPPORTED to the responder? The > initiator/responder roles could switch around at rekey, and it would > be useful to the initial responder (now initiator) whether or not it > can or should just start with TCP. Although it could deduce this from > having received a connection on TCP in the previous exchange. I'm not > sure on this one. I guess, but rekey doesn't require TCP, as it doesn't have the IKE_AUTH exchange. It may be useful so that next time the original responder can begin the Initial exchange with TCP. > > Paul > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New I-D on IKEv3
Hi Paul, On Sat, October 13, 2012 2:35 pm, Paul Wouters wrote: > On Fri, 12 Oct 2012, Dan Harkins wrote: > >> Subject: [IPsec] New I-D on IKEv3 > > Some remarks > > - stateless IKE > > I like not dealing with lingering IKE SA's, but how to tell if a > connection is dead? idletime on the IPsec SA? How to do DPD? That's a great question. There's alot of complexity that gets added for IKE to deal with DPD and I'd just like to punt that to something else. Idletime on the IPsec SAs is probably the way to do it. > When a roadwarrior pops up at IP A, and then at IP B, etc, how do > we get rid of IPsec SA A, B etc. Or do we ignore the outer IP completely > and don't care about SRC/DST of the ESP packets and just send answers > the the latest IP-port we saw? I think any stale SA would be cleaned up by the "something else" I referred to above. Figuring out where to send packets may require some linkage between outer and inner addresses when they get plumbed into the kernel that would orphan an "old" IPsec SA (and possibly facilitate it's cleanup). Which reminds me, one thing missing from IKEv3 is a "config mode". That really needs to be there. > - "Only one instance of the IKEv3 protocol SHALL be run at time between > any two peers." > > What about NAT, I guess you do mean "peers" and not "IPs" but can we > always tell? NAT detection is another thing I left out in my rush to hit the -00 cutoff date. I mean "peers" and the way we can tell is to include a "this is what I think my address is" payload. The recipient can then tell whether the other side is behind a NAT and disambiguate multiple "peers" behind the same IP address to enforce the "only one instance" requirement. > - algorithm selection > > The responder can look at the initiator SPI and match up its SPI lower > bits to give its own proposal a slight edge. Could that be problematic? The tie is only the case where both sides initiate simultaneously and that happens when neither side has seen the other's offer. There just needs to be some way to unambiguously converge on accepted parameters. Of course, an implementation can receive the other side's offer and respond as if it did not (make a tie that it will win) but a responder will always have a slight edge because he gets to see the initiator's offer before exposing his own. Provided that they converge on acceptable parameters, is this a problem? > - ID_BLOB_ID > > I like this! And already have a use for it > > - "and two Traffic Selector payloads (TS)" > > In IKEv2 and here I always found it very confusing to talk about > "Traffic Selector payload" payload and the "Traffic Selector" payload. > There should really be better terms for that. > > - I'm still not a fan of narrowing, see my earlier comments on ipsecme. >It destroys the concept of a tunnel being "up" or "down". If you >insist on narrowing, clearly state what should happen for traffic >selectors outside the narrowed set, DROPed or ACCEPTed plaintext? >Related: all the IKEv2 text about meaning of the first and second TS >payload is missing (eg the src/dst of the trigger and the src/dst of >the negiating SA). Was that intentional? It was not intentional to lose important information, it's just that that section is kind of verbose and I think can be stated more succinctly. If the IKEv3 text is missing important information, I will try to clean it up. > - Why still support AH? I have no love of AH but is it up to the key exchange protocol to kill off an IPsec protocol? > - What happened to NAT Traversal negotiation? back to vendorids? It will be in -01. > - Should compression be disallowed? I am agnostic on the subject and willing to follow the will of the group. Thanks alot for your comments; much appreciated. regards, Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
