[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
My emails to the ipsec list have been disappeared since Dec 3...
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