From hipsec-bounces@lists.ietf.org Mon Jun 04 08:10:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBOU-00084c-8w; Mon, 04 Jun 2007 08:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBOS-000846-Ac for hipsec@lists.ietf.org; Mon, 04 Jun 2007 08:10:40 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvBOQ-0007x8-04 for hipsec@lists.ietf.org; Mon, 04 Jun 2007 08:10:40 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id DF4BF2D38; Mon, 4 Jun 2007 15:10:36 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 75C492CE7; Mon, 4 Jun 2007 15:10:35 +0300 (EEST) Date: Mon, 4 Jun 2007 15:10:35 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing Subject: RE: [Hipsec] hip-nat-traversal-02-pre5 In-Reply-To: <092601c7a224$e8522b50$c6f0200a@amer.cisco.com> Message-ID: References: <092601c7a224$e8522b50$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org, 'Jonathan Rosenberg' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 29 May 2007, Dan Wing wrote: > Thanks for the opportunity to review this document before publication. Thanks for feedback and apologies for the long delay. The next preversion includes your comments and it is available here: http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre6.txt > Comments: > > 1. section 3: > > This section describes NAT traversal between two HIP end-hosts. A > successful NAT traversal requires at least the Responder to register > to a relay server. The base exchange is relayed through the relay > server. > > In the introduction you described three cases -- where the initiator is > behind a NAT, where the terminator is behind a NAT, and where both are > behind (different) NATs. In the second case, where the terminator > (HIP Responder, I presume?) is not behind a NAT but is on a public > network, is it true that it still needs to register to a relay server? If the responder is always in a public network, it has no need for a relay server. Added: "The use of the relay is optional when the Responder is located in a public address realm without rendezvous server" > 2. section 3: > > The end-hosts need a fixed transport layer port number to be able to > communicate with each other. The end-hosts MUST accept incoming HIP > and ESP traffic arriving at UDP port 50500 (future extensions may use > the same port number for TCP). It is RECOMMENDED that an Initiator > selects a random port number between 49152-65535 for initiating a > base exchange even for registration. However, the allocated port > MUST be maintained until all of the corresponding Host Associations > are closed. Alternatively, a host MAY also use source port 50500 for > initiating a base exchange. The RECOMMENDED transport layer protocol > is UDP. > > From this requirement, I can only assume that HIP doesn't communicate the > port number across th HIP rendezvous server. Is my assumption > corrrect? Your assumption is correct assuming you mean relay instead of rendezvous server. Should it communicate it? Actually, this brought to my mind a related idea that I did not include in the draft yet. The registration phase could be identical to the connectivity test phase, except there not may be a relay available yet and the packets are carrying REG parameters. In this case, the packets would also carry the locator information of the initiator to the relay. >From an implementation point of view, this would perhaps simplify implementations because currently registration and connectivity tests are handled differently. From a performance point of view, this would increase the latency in the registration to the relay server, but this probably is an acceptable cost. What do you think? > 3. section 3.1: > > When the ESP relay registration was successful, the relay server uses > the source IP address and port (typically 50500) of the R2 to relay > ESP traffic with the client. This address-port pair of the relay is > referred as "leased transport locator" in this document. > > Please delete "(typically 50500)", because earlier text allows using 50500 > as the source address or using the 49152-65535 range as the source address. Source port of the R2 is 50500 (i.e. the port the relay is listening) is 50500. The "typically" meant (now removed) that sometimes you may want to use non-default ports. > But more importantly, a NAT may be unable to retain whatever UDP port the > host chose because another host is already using that same UDP port, or > because the NAT doesn't like to retain source UDP ports. So -- what is > the significance of this choice of ephemeral port? If I recall correctly the original reason for this, it was the cone NATs. > 4. Section 3.2: > > The relay MUST change the transport > source and destination of the message to match the one the Responder > used when registrating to the relay. > > > Does this mean the relay spoofs the IP address? That is how I read it... > If you're referring to transport source and destination addresses inside of > HIP itself, the text needs to be clarified. If you really do want the relay > to spoof IP addresses, I think the design is flawed. I modified the text. What I meant that the relay forwards the message to the destination address the responder that it used in the registration. > 5. Section 3.2: > > The base > exchange was concluded by I2 and R2 messages over transport layer > that contained RELAY_TO parameters. > > After this, the state of the HIP > associations is ESTABLISHED, but the hosts MUST NOT allow any ESP > traffic until the connectivity tests described in the next section > are performed successfully. > > > But the next section (3.3) describes cases where there aren't connectivity > tests, even if there was a RELAY_TO. This needs to be cleaned up. I > suggest moving the last two paragraphs of 3.2 into 3.3, Done. > and not described ESTABLISHED as > some-state-that-isn't-quite-like-ESTABLISHED. I think you need to > transition to a different state (such as perhaps UNVERIFIED?), and > describe the rules for when you enter that state and when you can skip > that state and go directly to ESTABLISHED. I am not convinced yet that this is necessary. The draft proposes that ESTABLISHED means that the host associations are established, but the locators still have to be separately tested for return routability similarly as in draft-ietf-mm. > 6. Section 3.2: > > I don't think the FROM_PEER is sufficient to identify peers. Consider, for > example, that almost every consumer-grade NAT in the world uses 192.168.1.0 > as its private (internal) network, and the first host is typically assigned > 192.168.1.1, the second host .2, and so forth. Two HIP hosts behind their > own NATs could easily have the same private IP address, and could be trying > to establish communication with each other. In this case, FROM_PEER isn't > useful to distinguish connectivity checks from yourself versus from your > peer. Rather than using IP address, ICE uses a USERNAME, half of which is > chosen by each peer, to provide this distinguisher. I suggest using a > peer-selected value to identify each peer is superior to IP address as a > peer identifier. I am unconvinced that we should drag the usernames and passwords from ICE to HIP. HIP has alreadt a crypgraphically more secure identifiers in the form of public keys (which can btw include a NAI, such as foo@bar etc). > 7. Section 3.3: > > If the FROM_PEER and TO_PEER do not > match, the Responder is behind a "p2p-unfriendly" NAT > [I-D.ietf-behave-p2p-state]. > > I believe there are two cases where you'll still encounter that situation, > even if you are behind 100% p2p-friendly NATs. > > Case 1: you're behind two p2p-friendly NATs ("nested NATs"). > > Case 2: if you have a network topology like this, with 100% p2p-friendly > NATs, I believe they'll also not match: > > Rendezvous Server > / \ > / \ > / \ > Intiator------------NAT----Router > | > Responder > > That is, where a NAT is only on-path between the Initator and Responder, but > isn't on-path between Responder and its Rendezvous Server. There could be a > different NAT that is on-path between the Responder and its Rendezvous > Server. Such a situation can occur (and does occur) with NATs inside > enterprises. This situation is why ICE has 'triggered checks': for > situations where the ICE endpoint doesn't know its traffic will traverse a > NAT because the NAT isn't on-path with the ICE endpoint's STUN server. I believe the connectivity tests will detect this. Changed the text to "the responder may be behind.." > I encourage you to not use IP addresses as identifiers, especially for NAT > traversal. The HITs are used as the identifier. Both source and destination HITs are included in all HIP control packets. > 8. The first paragraph of section 3.3 burdens public hosts with NAT > keepalives: > > They MUST NOT > follow the extensions of this draft, except for the NAT keepalives > described in a later section. > > You don't need to create that burden: only the hosts behind NATs need to be > burdened with keeping their NAT pinholes alive. If I recall correctly, both directions are important to keep the NAT state alive, but the outgoing direction was more important. Is the incoming direction completely unimportant? > 9. The NAT keepalive section (section 3.6) needs to describe how often the > keepalives need to be sent. As I mentioned above, you don't need to burden > everyone with NAT keepalives -- just the hosts that are behind NATs. How do you detect which host actually is "behind" the NAT. The current document uses also this "behind" term loosely, but the protocol actually tests "between". > 10. Section 5, firewall traversal: > > There is an odd statement about NAT traversal that is included in the > firewall traversal section: > > The NAT traversal mechanisms described in Section 3 require that the > firewall - stateful or not - allow inbound UDP traffic to port 50500 > and allow outbound UDP traffic to arbitrary UDP ports. If necessary > for firewall traversal, ports reserved for IKE MAY be used for > initiating new connections, but the implementation MUST be able to > listen for UDP packets from port 50500. > > This needs to be made clearer. Here is an example of a topology that > wouldn't work if all the firewall did was the above paragraph: > > Rendezvous Server > \ > \ > Firewall > | > NAT > | > Responder > > The Rendezvous server would listen for traffic on UDP/50500. I modified the text, hope it is more clear now. > Nits: > > Nit 1: Introduction: > > This document > specifies how HIP can traverse through such NAT middleboxes which are > neither HIP-aware or ESP-aware without manual configuration of the > NAT devices. > > You're using the term "NAT middlebox" and "NAT devices" in the same > sentence. You should use one. I also found the "without manual > configuration" awkward to read; inserting a comma might help separate > out the two awareness clauses. Like this: > > ... neither HIP-aware or ESP aware, without manual ... > ^ > > Nit 2: The paragraph starting with: > > "The new namespace of HIP has some additional benefits." > > seems to need a transitional phrase or something; it sort of sticks out > there by itself. I think before that paragraph you need an introductory > paragraph describing the "HIP namespace". > > > Nit 3: > > OLD: > The protocol extensions in this document make > NEW: > The HIP extensions in this document make > ^^^ > > Nit 4: > > OLD: > the behavior of the NAT devices to make NAT traversal to work even > NEW: > the behavior of the NAT devices so that NAT traversal will work even > ^^^^^^^ ^^^^ Applied. > Nit 5: > Instead of repeating the procedure to choose the source port (50500 or in > that port range), how about describing it once in a tiny section and then > referring to that section everywhere in the document. > > It would be useful if the suggestion for 49152-65535 was clarified: does > something break if I were to use 49151, for example? > > (I found a discussion in section 5, "firewall traversal", which seemed to > describe why the selection of source port was useful. This should be > consolidated into one place.) Applied. What part of the firewall traversal did you find particarly useful? > Nit 6: Section 3.2: > > The source port is chosen randomly between the range > 49152-65535 and destination port is 50500. The destination address > is the relay address. The source address is one of the addresses of > the link, which are also referenced to as "unreflexive locators" in > ^^^^^^^^ > this document. > > "Links" don't have addresses; I think this should be 'one of the routable > addresses for the host' or something like that?? (I'm not sure) Changed to routable addresses. > Nit 7: Section 3.3: > > In the case of direct path, the hosts > prefer a path without transport layer encapsulation which means that > the hosts have no legacy NAT between them. > > This encapsulation has not previously been described in the document. Added references. > Question: is legacy NAT the only reason for UDP encapsulation? I would > think a firewall that doesn't like the HIP protocol number might also be > another reason. And perhaps also another case is an operating system that > doesn't understand HIP, where HIP is done entirely by the application? I do > not know HIP well enough to answer these two questions. You are right. Added the HIP protocol issue. Did not add the operating system issue because it is an implementation issue. > Nit 8: Section 3.3: > > The > Initiator MUST pace the NOTIFY messages sequentially 20 ms apart (as > explained in [I-D.ietf-mmusic-ice]). > > FYI, this ICE pacing algorithm is going to be changed. See Sally Floyd's > response to my email about those upcoming changes at: > http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00085.html Thanks for the reference. For the time being, the draft is just referencing ICE on the pacing. > Nit 9: section 8: > > Thanks for Jonathan > Rosenberg and the rest of the ICE WG folks for the excellent work on > ^^^^^^ > ICE. > > ICE is a product of the MMUSIC working group. Sorry, my bad. Corrected. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 04 21:16:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvNeu-0007Nn-Jz; Mon, 04 Jun 2007 21:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvNet-0007Nc-Q7 for hipsec@lists.ietf.org; Mon, 04 Jun 2007 21:16:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvNeq-0007Fc-PH for hipsec@lists.ietf.org; Mon, 04 Jun 2007 21:16:27 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 04 Jun 2007 18:16:24 -0700 X-IronPort-AV: i="4.16,382,1175497200"; d="scan'208"; a="158818263:sNHT63622980" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l551GOcE024786; Mon, 4 Jun 2007 18:16:24 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l551GK06027678; Tue, 5 Jun 2007 01:16:21 GMT From: "Dan Wing" To: "'Miika Komu'" Subject: RE: [Hipsec] hip-nat-traversal-02-pre5 Date: Mon, 4 Jun 2007 18:16:20 -0700 Message-ID: <072401c7a70f$21b5d060$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcemoV/E6mdQK+vMR0aWpcAaep4rowAaUhAg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11310; t=1181006184; x=1181870184; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Hipsec]=20hip-nat-traversal-02-pre5 |Sender:=20; bh=2otgKlGIzcE6zisnRMM4tCJdwyes9vKXgOUCsVGhiJ0=; b=bvyxFDaOAVRTHat5/QKmCzYxHWawrObWupnarfzIbbBeBIgSMKztw+km+HPtsCEGEYrric/4 70uthPpHBPoZCqesggNgNMcd5WLfF49QSPGEU/QI7k9xeBfATQfobwRe; Authentication-Results: sj-dkim-5; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org, 'Jonathan Rosenberg' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > Thanks for feedback and apologies for the long delay. The > next preversion includes your comments and it is available here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre6.txt I'll look at that tomorrow or Wednesday. ... > > From this requirement, I can only assume that HIP doesn't > > communicate the > > port number across th HIP rendezvous server. Is my assumption > > corrrect? > > Your assumption is correct assuming you mean relay instead of > rendezvous server. Should it communicate it? Yes, at the same time you communicate the IP address, because you can't assume the remote peer will be able to obtain the expected UDP port --- the NAT may very well have given a different host that UDP port already. > Actually, this brought to my mind a related idea that I did not > include in the draft yet. The registration phase could be > identical to the connectivity test phase, except there not may > be a relay available yet and the packets are carrying REG > parameters. In this case, the packets would also carry the > locator information of the initiator to the relay. That sounds similar to what ICE does. Which brings up a huge meta-question: why don't you just define how to do an offer in HIP and an answer in HIP, and use ICE? This way you'd be sure to function all the time, as ICE has gone through tons of peer review to ensure it always works in the weirdest of network topologies. > From an implementation point of view, this would perhaps simplify > implementations because currently registration and > connectivity tests are handled differently. From a performance > point of view, this would increase the latency in the registration > to the relay server, but this probably is an acceptable cost. > > What do you think? I'd need to digest the suggestion some more. As you know, I'm not very hip in my understanding of HIP. > > 3. section 3.1: > > > > When the ESP relay registration was successful, the relay > > server uses > > the source IP address and port (typically 50500) of the > > R2 to relay > > ESP traffic with the client. This address-port pair of > > the relay is > > referred as "leased transport locator" in this document. > > > > Please delete "(typically 50500)", because earlier text > > allows using 50500 > > as the source address or using the 49152-65535 range as the > > source address. > > Source port of the R2 is 50500 (i.e. the port the relay is > listening) is > 50500. The "typically" meant (now removed) that sometimes you > may want to use non-default ports. If you only removed the word 'typically', and it now reads: ... the source IP address and port (50500) ... then I'm really worried -- what happens when two hosts behind the same NAT need to get that same port? > > But more importantly, a NAT may be unable to retain > > whatever UDP port the > > host chose because another host is already using that same > > UDP port, or > > because the NAT doesn't like to retain source UDP ports. > > So -- what is > > the significance of this choice of ephemeral port? > > If I recall correctly the original reason for this, it was > the cone NATs. Relying on the source port always being 50500 won't work at all, though, if there are two hosts behind the same NAT -- no matter what kind of NAT you're considering. Here is a concrete example of the problem I'm describing: | +--+--+ | NAT | ++---++ | | +---+ +----+ | | | | host-a host-b The HIP stack on Host-A gets UDP/50500, and the HIP stack on Host-B gets UDP/50500. One of them will be first to send a UDP packet across the HIP-unaware NAT. Let's pretend the winner is Host-A. Host-B, when he sends his UDP packet across the NAT, the NAT cannot give Host-B port 50000 (because it's being used by Host-A); instead, the NAT will get some other UDP port from the range 1024-65535 (which is all that is required by the BEHAVE UDP specification). By the way, the BEHAVE UDP specification is purposefully silent about port preservation -- thus, there is no encouragement that NATs preserve ports. This is by design, because relying on port preservation fails if another application (on the same host) recently used the port or another host (behind the same NAT) recently used the same port. Thus, such a reliance creates a fragile system that worked fine during product development (when the developer had a single host and a single NAT). ... > > and not described ESTABLISHED as > > some-state-that-isn't-quite-like-ESTABLISHED. I think you need to > > transition to a different state (such as perhaps UNVERIFIED?), and > > describe the rules for when you enter that state and when > > you can skip > > that state and go directly to ESTABLISHED. > > I am not convinced yet that this is necessary. The draft > proposes that > ESTABLISHED means that the host associations are established, but the > locators still have to be separately tested for return routability > similarly as in draft-ietf-mm. Ok, I'll re-read it with that in mind. > > 6. Section 3.2: > > > > I don't think the FROM_PEER is sufficient to identify > > peers. Consider, for > > example, that almost every consumer-grade NAT in the world > > uses 192.168.1.0 > > as its private (internal) network, and the first host is > > typically assigned > > 192.168.1.1, the second host .2, and so forth. Two HIP > > hosts behind their > > own NATs could easily have the same private IP address, and > > could be trying > > to establish communication with each other. In this case, > > FROM_PEER isn't > > useful to distinguish connectivity checks from yourself > > versus from your > > peer. Rather than using IP address, ICE uses a USERNAME, > > half of which is > > chosen by each peer, to provide this distinguisher. I > > suggest using a > > peer-selected value to identify each peer is superior to IP > > address as a > > peer identifier. > > I am unconvinced that we should drag the usernames and > passwords from ICE to HIP. HIP has alreadt a crypgraphically > more secure identifiers in the form of public keys (which can > btw include a NAI, such as foo@bar etc). (ICE doesn't use the STUN username and password fields for cryptographic security (or, really, any sort of real security); it uses them to ensure that connectivity has been established with the desired peer. Please ignore the names of the fields; they are carryovers from STUN's (RFC3489) original purpose and really are misnomers when considered with ICE's connectivity checks.) Based on a comment you made below, it seems you're using HIT as a similar peer identifier? If so, what is the purpose of FROM_PEER? > > 7. Section 3.3: > > > > If the FROM_PEER and TO_PEER do not > > match, the Responder is behind a "p2p-unfriendly" NAT > > [I-D.ietf-behave-p2p-state]. > > > > I believe there are two cases where you'll still encounter > > that situation, > > even if you are behind 100% p2p-friendly NATs. > > > > Case 1: you're behind two p2p-friendly NATs ("nested NATs"). > > > > Case 2: if you have a network topology like this, with > > 100% p2p-friendly > > NATs, I believe they'll also not match: > > > > Rendezvous Server > > / \ > > / \ > > / \ > > Intiator------------NAT----Router > > | > > Responder > > > > That is, where a NAT is only on-path between the Initator > > and Responder, but > > isn't on-path between Responder and its Rendezvous Server. > > There could be a > > different NAT that is on-path between the Responder and its > > Rendezvous > > Server. Such a situation can occur (and does occur) with > > NATs inside > > enterprises. This situation is why ICE has 'triggered checks': for > > situations where the ICE endpoint doesn't know its traffic > > will traverse a > > NAT because the NAT isn't on-path with the ICE endpoint's > > STUN server. > > I believe the connectivity tests will detect this. Hmkay, I'll diagram it again on my whiteboard and try to figure out how your connectivity checks will resolve this situation. > Changed > the text to "the responder may be behind.." > > > I encourage you to not use IP addresses as identifiers, > > especially for NAT traversal. > > The HITs are used as the identifier. Both source and > destination HITs are included in all HIP control packets. Ah. Thanks. > > 8. The first paragraph of section 3.3 burdens public hosts with NAT > > keepalives: > > > > They MUST NOT > > follow the extensions of this draft, except for the NAT keepalives > > described in a later section. > > > > You don't need to create that burden: only the hosts > > behind NATs need to be > > burdened with keeping their NAT pinholes alive. > > If I recall correctly, both directions are important to keep > the NAT state > alive, but the outgoing direction was more important. > Is the incoming direction completely unimportant? That's correct: the NAT doesn't really care if a packet is received ouside->inside; sending a packet inside->outside is what creates the initial state and also what resets the timer. > > 9. The NAT keepalive section (section 3.6) needs to > > describe how often the > > keepalives need to be sent. As I mentioned above, you > > don't need to burden > > everyone with NAT keepalives -- just the hosts that are behind NATs. > > How do you detect which host actually is "behind" the NAT. > The current > document uses also this "behind" term loosely, but the > protocol actually > tests "between". This was just an observation I had about an optimization you could make, not an important point. If you were using STUN, your STUN Response would tell you if you're behind a NAT. If you are, then you have to generate some kind of keepalive. Likewise for the peer you're talking to -- they would learn (via an identical mechanism) if they're behind a NAT. This is learnable per flow. You may well be able to do a similar optimization for HIP. The advantage of doing such an optimization is you drop the number of packets necessary for your keepalive traffic by half. This can be very valuable on some networks (3G, for example). ... > > It would be useful if the suggestion for 49152-65535 was > clarified: does > > something break if I were to use 49151, for example? > > > > (I found a discussion in section 5, "firewall traversal", > which seemed to > > describe why the selection of source port was useful. This > should be > > consolidated into one place.) > > Applied. What part of the firewall traversal did you find particarly > useful? There were a few sentences that explained how, if everyone used the same ports for HIP, a firewall could trust that all use of those ports was HIP and could permit that traffic through the firewall. -d _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 05 05:42:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVYs-0000H9-Bi; Tue, 05 Jun 2007 05:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVYq-0000GK-Na for hipsec@lists.ietf.org; Tue, 05 Jun 2007 05:42:44 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVYp-00026e-2z for hipsec@lists.ietf.org; Tue, 05 Jun 2007 05:42:44 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 467502D18; Tue, 5 Jun 2007 12:42:42 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 471512CE0; Tue, 5 Jun 2007 12:42:41 +0300 (EEST) Date: Tue, 5 Jun 2007 12:42:41 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing Subject: RE: [Hipsec] hip-nat-traversal-02-pre5 In-Reply-To: <072401c7a70f$21b5d060$c2f0200a@amer.cisco.com> Message-ID: References: <072401c7a70f$21b5d060$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org, 'Jonathan Rosenberg' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 4 Jun 2007, Dan Wing wrote: >> Your assumption is correct assuming you mean relay instead of >> rendezvous server. Should it communicate it? > > Yes, at the same time you communicate the IP address, because you can't > assume the remote peer will be able to obtain the expected UDP port --- > the NAT may very well have given a different host that UDP port already. The current draft assumes that the same port (50500) of the relay can be used by several hosts. The multiplexing is done based on the ESP SPI numbers and not the UDP port. This description is still missing from the draft. If we want to multiplex just based on the UDP port number, the relay client needs to punch a separate hole into its NAT and keep it alive separately. I think this would actually require the registration to include the connectivity test phase. A benefit of this could be that the UDP port could be allocated also from a regular STUN server. >> Actually, this brought to my mind a related idea that I did not >> include in the draft yet. The registration phase could be >> identical to the connectivity test phase, except there not may >> be a relay available yet and the packets are carrying REG >> parameters. In this case, the packets would also carry the >> locator information of the initiator to the relay. > > That sounds similar to what ICE does. > > Which brings up a huge meta-question: why don't you just define > how to do an offer in HIP and an answer in HIP, and use ICE? This > way you'd be sure to function all the time, as ICE has gone through > tons of peer review to ensure it always works in the weirdest of > network topologies. Well, I guess the meta-answer is that HIP is not SIP. How would you design the protocol based on offer/answer? Could illustrate with a simple flow diagram? Please also illustrate the handover. To me, the current draft is ICE fitted to the HIP protocol. We have already a base exchange protocol and mobility extensions for non-natted environments, so it made sense to me to reuse the existing mechanism for NATted environments. For example, registration is a base exhange and the connectivity test is almost the same as a mobility handover. A separate protocol mechanism would introduce larger code base for implementations which is not very nice. >> Source port of the R2 is 50500 (i.e. the port the relay is >> listening) is >> 50500. The "typically" meant (now removed) that sometimes you >> may want to use non-default ports. > > If you only removed the word 'typically', and it now reads: > > ... the source IP address and port (50500) ... > > then I'm really worried -- what happens when two hosts behind the same NAT > need to get that same port? See the SPI discussion above. >>> But more importantly, a NAT may be unable to retain >>> whatever UDP port the >>> host chose because another host is already using that same >>> UDP port, or >>> because the NAT doesn't like to retain source UDP ports. >>> So -- what is >>> the significance of this choice of ephemeral port? >> >> If I recall correctly the original reason for this, it was >> the cone NATs. > > Relying on the source port always being 50500 won't work at all, though, if > there are two hosts behind the same NAT -- no matter what kind of NAT you're > considering. > > Here is a concrete example of the problem I'm describing: > > | > +--+--+ > | NAT | > ++---++ > | | > +---+ +----+ > | | > | | > host-a host-b > > > The HIP stack on Host-A gets UDP/50500, and the HIP stack on Host-B gets > UDP/50500. One of them will be first to send a UDP packet across the > HIP-unaware NAT. Let's pretend the winner is Host-A. Host-B, when he sends > his UDP packet across the NAT, the NAT cannot give Host-B port 50000 > (because it's being used by Host-A); instead, the NAT will get some other > UDP port from the range 1024-65535 (which is all that is required by the > BEHAVE UDP specification). > > By the way, the BEHAVE UDP specification is purposefully silent about port > preservation -- thus, there is no encouragement that NATs preserve ports. > This is by design, because relying on port preservation fails if another > application (on the same host) recently used the port or another host > (behind the same NAT) recently used the same port. Thus, such a reliance > creates a fragile system that worked fine during product development (when > the developer had a single host and a single NAT). I fail to see the problem here. The fixed port number is for receiving packets, either at the relay server or when the hosts are behind the same NAT. When a host is behind NAT(s), the NAT(s) will translate the port. The host can discover the translated port number (reflexive relay locator) from the relay or during connectivity tests (reflexive peer locator). These reflexive addresses are given/discovered by the peer and the peer will use them to communicate with the host. It does not really matter whether the NAT preserves the port or not as the translated port is sent to peer. If there is something said unclearly in the document about this, please give specific pointers to the text and/or suggestions to corrections. > (ICE doesn't use the STUN username and password fields for > cryptographic security (or, really, any sort of real security); > it uses them to ensure that connectivity has been established > with the desired peer. Please ignore the names of the fields; > they are carryovers from STUN's (RFC3489) original purpose and > really are misnomers when considered with ICE's connectivity > checks.) > > Based on a comment you made below, it seems you're using HIT > as a similar peer identifier? Yes. > If so, what is the purpose of FROM_PEER? To discover the reflexive peer locators. See step 4 in section section 3.4. >>> 8. The first paragraph of section 3.3 burdens public hosts with NAT >>> keepalives: >>> >>> They MUST NOT >>> follow the extensions of this draft, except for the NAT keepalives >>> described in a later section. >>> >>> You don't need to create that burden: only the hosts >>> behind NATs need to be >>> burdened with keeping their NAT pinholes alive. >> >> If I recall correctly, both directions are important to keep >> the NAT state >> alive, but the outgoing direction was more important. >> Is the incoming direction completely unimportant? > > That's correct: the NAT doesn't really care if a packet is > received ouside->inside; sending a packet inside->outside is > what creates the initial state and also what resets the timer. > >>> 9. The NAT keepalive section (section 3.6) needs to >>> describe how often the >>> keepalives need to be sent. As I mentioned above, you >>> don't need to burden >>> everyone with NAT keepalives -- just the hosts that are behind NATs. >> >> How do you detect which host actually is "behind" the NAT. >> The current >> document uses also this "behind" term loosely, but the >> protocol actually >> tests "between". > > This was just an observation I had about an optimization you could > make, not an important point. This optimization could require some additional STUN-like tricks in the HIP NAT traversal protocol, like answering from a different port and/or IP address. This would introduce extra complexity to the protocol. > If you were using STUN, your STUN Response would tell > you if you're behind a NAT. If you are, then you have to generate > some kind of keepalive. Likewise for the peer you're talking to -- > they would learn (via an identical mechanism) if they're behind a > NAT. This is learnable per flow. > > You may well be able to do a similar optimization for HIP. The > advantage of doing such an optimization is you drop the number > of packets necessary for your keepalive traffic by half. This > can be very valuable on some networks (3G, for example). Is STUN NAT detection 100 % sure with legacy NATs? If not, the optimization does not work in 100 % of the cases. Yes, the dual-directional keepalives double the traffic, but they are also used for path failure detection. See section 3.7. I still remain unconvinced that the optimization is worth it. > ... >>>It would be useful if the suggestion for 49152-65535 was >> clarified: does >>> something break if I were to use 49151, for example? >>> >>> (I found a discussion in section 5, "firewall traversal", >> which seemed to >>> describe why the selection of source port was useful. This >> should be >>> consolidated into one place.) >> >> Applied. What part of the firewall traversal did you find particarly >> useful? > > There were a few sentences that explained how, if everyone used > the same ports for HIP, a firewall could trust that all use of > those ports was HIP and could permit that traffic through the > firewall. The port for the host inside the firewall can be emphemeral and for the host outside of the firewall it is always 50500. I don't think it is necessary to require that both ports are 50500. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 05 13:13:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvcb1-00047q-7D; Tue, 05 Jun 2007 13:13:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvcaz-00047l-SA for hipsec@lists.ietf.org; Tue, 05 Jun 2007 13:13:25 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvcay-0001o8-Ml for hipsec@lists.ietf.org; Tue, 05 Jun 2007 13:13:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 05 Jun 2007 10:13:24 -0700 X-IronPort-AV: i="4.16,386,1175497200"; d="scan'208"; a="161051833:sNHT78681114" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l55HDOeQ017205; Tue, 5 Jun 2007 10:13:24 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l55HDG06002330; Tue, 5 Jun 2007 17:13:16 GMT From: "Dan Wing" To: "'Miika Komu'" Subject: RE: [Hipsec] hip-nat-traversal-02-pre5 Date: Tue, 5 Jun 2007 10:13:16 -0700 Message-ID: <093e01c7a794$d2ccbd20$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcenVePYrySvU4G1QtyFGVTxjfAVTwANpmuw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21317; t=1181063604; x=1181927604; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Hipsec]=20hip-nat-traversal-02-pre5 |Sender:=20; bh=3Ctjr2h8Q5uTyPjY9oLNbZxfxg/UtLem01vv29uvM6I=; b=YL+eR8CoxCQZDvKeTlXngsj7Ts5qSy3TGfe699jo2XcmbBHGhiRnhRM6K5iNGTA2RJoTkAsn +wQ/NU7wM2V1MyFcKDR7DWEbvFac6l/uyJ+bjeI6i2dzGeeoeZXMiE7X; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org, 'Jonathan Rosenberg' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > >> Your assumption is correct assuming you mean relay instead of > >> rendezvous server. Should it communicate it? > > > > Yes, at the same time you communicate the IP address, > > because you can't > > assume the remote peer will be able to obtain the expected > > UDP port --- > > the NAT may very well have given a different host that UDP > > port already. > > The current draft assumes that the same port (50500) of the > relay can be > used by several hosts. The multiplexing is done based on the ESP SPI > numbers and not the UDP port. But you can only accomplish that multiplexing after you're doing IPSec ESP -- HIP runs before that, I think? > This description is still > missing from the draft. > > If we want to multiplex just based on the UDP port number, the relay > client needs to punch a separate hole into its NAT and keep it alive > separately. I think this would actually require the registration to > include the connectivity test phase. A benefit of this could be that > the UDP port could be allocated also from a regular STUN server. Right. > >> Actually, this brought to my mind a related idea that I did not > >> include in the draft yet. The registration phase could be > >> identical to the connectivity test phase, except there not may > >> be a relay available yet and the packets are carrying REG > >> parameters. In this case, the packets would also carry the > >> locator information of the initiator to the relay. > > > > That sounds similar to what ICE does. > > > > Which brings up a huge meta-question: why don't you just define > > how to do an offer in HIP and an answer in HIP, and use ICE? This > > way you'd be sure to function all the time, as ICE has gone through > > tons of peer review to ensure it always works in the weirdest of > > network topologies. > > Well, I guess the meta-answer is that HIP is not SIP. ICE does not require SIP. XMPP (Jabber) has implemented ICE, but XMPP is not SIP. XMPP did not have an offer/answer model, but in order to use ICE as-is, they determined how to create one in XMPP, and XMPP exchanges the information needed by ICE between the two endpoints to accomplish the NAT traversal. > How would you design the protocol based on offer/answer? offer: - gather candidate IP addresses and UDP ports - send those candidate IP addresses and UDP ports to your intended HIP peer, via your rendezvous server. answer: - have your intended HIP peer gather its candidate IP addresses and UDP ports - have your intended HIP peer send its candidate IP addresses and UDP ports back to the offerer, via your rendezvous server. As soon as one side learns the candidate addresses of the other side it can immediately begin doing connectivity checks. For HIP, you might want to map your two HIT identifiers directly into the STUN username field; you are already communicating your HIT to your intended peer anyway. > Could > illustrate with a simple flow diagram? Please also illustrate > the handover. Offer NAT STUN server rendezvous server Answerer | | | | | 1 |---------------->| | | 2 |<----------------| | | 3 |-------------------------------->| | 4 | | | |------------------->| 5 | X<=============================================| 6 | | | |<-------------------| 7 |<--------------------------------| | 8 |=====================================================>| 9 |<=====================================================| 10 |<=====================================================| 11 |=====================================================>| 1. gather candidates (send STUN binding request) 2. receive STUN binding response 3. send candidates to intended peer, via rendezvous server 4. message continues from rendezvous server to intended peer 5. intended peer does a connectivity check, which is dropped by the NAT (let's pretend the NAT does some filtering, otherwise this message flow wouldn't be very interesting). 6. intended peer isn't behind a NAT, so doesn't bother with the candidate gathering; if it was behind a NAT, it would do its own candidate gathering. This isn't shown in this message flow to keep it a little simplier. Message 6 shows the intended peer replying with its candidate address (which is its own IP address and UDP port). 7. Answer is relayed, via the rendezvous server, to the offerer. The offerer now has the answerer's candidate IP addresses and candidate UDP ports. 8. Offerer sends a STUN Binding Request packet directly to the answerer's candidate IP address. This is received by the answerer (the intended peer) 9. Answerer sends STUN Binding Response. when offerer receives this message, the offerer knows -- without any doubt -- that it is communicating to the correct host (because that correct host proved it because it created a valid SHA1 HMAC of the message). It can now communicate with it -- in HIP's case, initiate your HIP exchange with the peer and initiate IPsec ESP. 10. A so-called "triggered check" occurs, (due to receiving message 8), which causes the answerer to immediately send a STUN Binding Request to check its connectivity with the intended peer (the offerer). This is really an accelerated re-transmit of message 5 (which was dropped by the offerer's NAT, due to his NAT's filtering rules). 11. STUN response is sent, and received by the answerer. It now knows it has bi-directional communication with the offerer. > To me, the current draft is ICE fitted to the HIP protocol. There are significant differences; for example, ICE doesn't use IP addresses as identifiers, because they are rendered meaningless with overlapped IP address space (192.168.1.2, commonly given to everyone's PC behind a Linksys/DLink/Belkin NAT). The mechanism in HIP-NAT-TRAVERSAL seems to use IP addresses as identifiers. > We have already a base exchange protocol and mobility > extensions for non-natted environments, so it made sense to > me to reuse the existing mechanism for NATted environments. > For example, registration is a base exhange and the > connectivity test is almost the same as a mobility handover. I agree reusing those is useful; I think more of the stuff that's in ICE -- using an identifier other than IP address and proving proof of some private information (exchanged via the rendezvous server between the intended peers) would go a long way towards thwarting accidental association with the wrong peer and towards thwarting attackers interfering with handover. > A separate protocol mechanism would introduce larger > code base for implementations which is not very nice. Understood. However, we need to tease apart the differences between what ICE is doing -- successfully on the Internet -- and what you're proposing to do, and make sure HIP's NAT traversal will be as successful when HIP needs to traverse non-HIP-aware NATs. Saving a few hundred lines of code isnn't the desired goal; successful operation on today's Internet is the desired goal. > >> Source port of the R2 is 50500 (i.e. the port the relay is > >> listening) is > >> 50500. The "typically" meant (now removed) that sometimes you > >> may want to use non-default ports. > > > > If you only removed the word 'typically', and it now reads: > > > > ... the source IP address and port (50500) ... > > > > then I'm really worried -- what happens when two hosts > > behind the same NAT > > need to get that same port? > > See the SPI discussion above. > > >>> But more importantly, a NAT may be unable to retain > >>> whatever UDP port the > >>> host chose because another host is already using that same > >>> UDP port, or > >>> because the NAT doesn't like to retain source UDP ports. > >>> So -- what is > >>> the significance of this choice of ephemeral port? > >> > >> If I recall correctly the original reason for this, it was > >> the cone NATs. > > > > Relying on the source port always being 50500 won't work at > all, though, if > > there are two hosts behind the same NAT -- no matter what > kind of NAT you're > > considering. > > > > Here is a concrete example of the problem I'm describing: > > > > | > > +--+--+ > > | NAT | > > ++---++ > > | | > > +---+ +----+ > > | | > > | | > > host-a host-b > > > > > > The HIP stack on Host-A gets UDP/50500, and the HIP stack > on Host-B gets > > UDP/50500. One of them will be first to send a UDP packet > across the > > HIP-unaware NAT. Let's pretend the winner is Host-A. > Host-B, when he sends > > his UDP packet across the NAT, the NAT cannot give Host-B port 50000 > > (because it's being used by Host-A); instead, the NAT will > get some other > > UDP port from the range 1024-65535 (which is all that is > required by the > > BEHAVE UDP specification). > > > > By the way, the BEHAVE UDP specification is purposefully > silent about port > > preservation -- thus, there is no encouragement that NATs > preserve ports. > > This is by design, because relying on port preservation > fails if another > > application (on the same host) recently used the port or > another host > > (behind the same NAT) recently used the same port. Thus, > such a reliance > > creates a fragile system that worked fine during product > development (when > > the developer had a single host and a single NAT). > > I fail to see the problem here. The fixed port number is for > receiving > packets, either at the relay server or when the hosts are > behind the same NAT. We must be talking past each other. If the hosts are behind the same NAT, they're going to get different source UDP ports -- that's how every sane NAT functions. There can be no successful, properly operating NAT that does port overloading -- it doesn't work. That's why it's a MUST NOT in the BEHAVE UDP specification. > When a host is behind NAT(s), the NAT(s) will translate the > port. The host > can discover the translated port number (reflexive relay > locator) from the > relay or during connectivity tests (reflexive peer locator). These > reflexive addresses are given/discovered by the peer and the > peer will use > them to communicate with the host. > > It does not really matter whether the NAT preserves the port > or not as the > translated port is sent to peer. If there is something said > unclearly in > the document about this, please give specific pointers to the > text and/or > suggestions to corrections. Yes, the document states that the source UDP port 50500 is retained when the UDP port traverses the NAT. Specifically: 3.1. Port Number Selection The end-hosts need a fixed transport layer port number to be able to communicate with each other. The end-hosts MUST accept incoming HIP and ESP traffic arriving at UDP port HIPPORT (future extensions may use the same port number for TCP). If an end-host already registers with a rendezvous server, I don't see the need for assignment of a fixed UDP port. Furthermore, if the end host does allocate HIPPORT for use by HIP and that host is behind a NAT, then from the perspective of all the other hosts on the Internet, the NAT _is_ the end host. And of course if that NAT has already allocated HIPPORT to another host behind the same NAT, the NAT cannot also allocate the same HIPPORT to this (new) host. Thus, you need to communicate both an IP address and UDP port to the rendezvous server. Section 3.2: ... When the ESP relay registration was successful, the relay server uses the source IP address and port HIPPORT of the R2 packet to relay ESP traffic with the client. ... Same problem -- the relaying agent (on the Internet) can't send traffic to HIPPORT; it needs to send traffic to whatever UDP port was used to communicate with the relay agent. (The text in 3.3, which describes this same relaying again, describes it correctly; it says: The relay MUST change the transport source to and destination of the packet to match the values the Responder used when registering to the relay, i.e., the reverse of the R2 used in the registration. ) One new comment I have, is text in section 5, which reads: When the Initiator is behind a firewall, the NAT traversal mechanisms described in Section 3 depend on the ability to initiate communication via UDP to the destination port HIPPORT from arbitrary source ports and to receive UDP response traffic from that port to the chosen source port. If the Initiator is behind a firewall that does not support "UDP connection tracking", the NAT traversal mechanisms described in Section 3 can still be supported, if the firewall allows permanently inbound UDP traffic from the port HIPPORT and destined to arbitrary source IP addresses and UDP ports. It should be noted, though, that if there is a NAT between the hosts and the firewall, the use of the source HIPPORT won't be useful: PC ---\ PC ---\\ PC ----++--[NAT]----[firewall] PC ---// PC ---/ because if all those PCs use the source HIPPORT, only the first one to cause a UDP packet to traverse the NAT has any chance of getting the NAT to map that same HIPPORT to the NAT's source UDP port. The other 4 PCs will lose. > > (ICE doesn't use the STUN username and password fields for > > cryptographic security (or, really, any sort of real security); > > it uses them to ensure that connectivity has been established > > with the desired peer. Please ignore the names of the fields; > > they are carryovers from STUN's (RFC3489) original purpose and > > really are misnomers when considered with ICE's connectivity > > checks.) > > > > Based on a comment you made below, it seems you're using HIT > > as a similar peer identifier? > > Yes. > > > If so, what is the purpose of FROM_PEER? > > To discover the reflexive peer locators. See step 4 in > section section 3.4. Ok. I'm still unclear on its overall purpose, but I did find the following in section 3.4: If the FROM_PEER and TO_PEER do not match, the Responder may be behind a "p2p-unfriendly" NAT [I-D.ietf-behave-p2p-state]. This means the NAT does not preserve the transport locator of the Responder when it communicates with multiple hosts. This kind of address-port pair is referred as "peer reflexive transport locator". The Initiator MUST store the transport address for later processing. The Initiator MUST transition the corresponding locator pair to ACTIVE state. and in section 2 (introduction): In contrast, the relay service relays all HIP control packets because p2p-unfriendly NAT devices drop the packets otherwise [I-D.ietf-behave-p2p-state]. With ICE, there is one and only one case where a relay is needed. That is when _BOTH_ peers are behind p2p-unfriendly NATs. If only one of the peers is behind a p2p-unfriendly NAT, a relay is not needed. We can design the same thing for HIP. This is very desirable, I would expect; everyone prefers to avoid relays. > >>> 8. The first paragraph of section 3.3 burdens public > hosts with NAT > >>> keepalives: > >>> > >>> They MUST NOT > >>> follow the extensions of this draft, except for the NAT > keepalives > >>> described in a later section. > >>> > >>> You don't need to create that burden: only the hosts > >>> behind NATs need to be > >>> burdened with keeping their NAT pinholes alive. > >> > >> If I recall correctly, both directions are important to keep > >> the NAT state > >> alive, but the outgoing direction was more important. > >> Is the incoming direction completely unimportant? > > > > That's correct: the NAT doesn't really care if a packet is > > received ouside->inside; sending a packet inside->outside is > > what creates the initial state and also what resets the timer. > > > >>> 9. The NAT keepalive section (section 3.6) needs to > >>> describe how often the > >>> keepalives need to be sent. As I mentioned above, you > >>> don't need to burden > >>> everyone with NAT keepalives -- just the hosts that are > behind NATs. > >> > >> How do you detect which host actually is "behind" the NAT. > >> The current > >> document uses also this "behind" term loosely, but the > >> protocol actually > >> tests "between". > > > > This was just an observation I had about an optimization you could > > make, not an important point. > > This optimization could require some additional STUN-like > tricks in the HIP NAT traversal protocol, like answering from > a different port and/or IP address. This would introduce extra > complexity to the protocol. I believe you are referring to the mechanisms described originally in RFC3489 in now described in draft-ietf-behave-nat-behavior-discovery. That is not needed to determine if you are behind a NAT; rather, those complex steps are only needed to diagnose what *kind* of NAT you are behind. I do not recommend those procedures for anything; they are fragile at best, and inaccurate at worst. Their purpose in draft-ietf-behave-nat-behavior-discovery is to assist in writing diagnostic tools. Their fragility, and the fact that ICE doesn't need those procedures, is why they were removed from the update to RFC3489 (draft-ietf-behave-rfc3489bis doesn't mention those procedures at all). Rather, I was suggesting just determining if you were behind a NAT; that's trivial. There are two cases: * your device wasn't configured with the IP address of a STUN server, which means you must not be behind a NAT (or else you would have been given the IP address of a STUN server in order to do candidate gathering) * if you were configured with a STUN server, you can send it a Binding Request packet when your software first initializes. If the Binding Response indicates a different transport address (transport locator, in HIP's terms, I guess?), then you know you're behind a NAT. Thereafter, whenever you establish UDP communications that cross that NAT, you know you should be doing keepalives. You would know if your UDP communications crossed that NAT by sending a STUN Binding Request (or a HIP message that is functionally the same) and learning that your peer saw that IP packet arrive from a different transport address than you sent it from -- which means a NAT was along that path that you are responsible for keeping alive its binding. > > If you were using STUN, your STUN Response would tell > > you if you're behind a NAT. If you are, then you have to generate > > some kind of keepalive. Likewise for the peer you're talking to -- > > they would learn (via an identical mechanism) if they're behind a > > NAT. This is learnable per flow. > > > > You may well be able to do a similar optimization for HIP. The > > advantage of doing such an optimization is you drop the number > > of packets necessary for your keepalive traffic by half. This > > can be very valuable on some networks (3G, for example). > > Is STUN NAT detection 100 % sure with legacy NATs? If not, the > optimization does not work in 100 % of the cases. > > Yes, the dual-directional keepalives double the traffic, but > they are also > used for path failure detection. See section 3.7. Yes, I agree they're useful for path failure detection; I figured you would have a different technique for that, as it's useful to detect path failure even without NATs. > I still remain unconvinced that the optimization is worth it. That's fine. As I said, it isn't a big deal; it can be done later without interoperability problems, too, so it's safe to defer it until there is a need to reduce keepalive traffic by half. > > ... > >>>It would be useful if the suggestion for 49152-65535 was > >> clarified: does > >>> something break if I were to use 49151, for example? > >>> > >>> (I found a discussion in section 5, "firewall traversal", > >> which seemed to > >>> describe why the selection of source port was useful. This > >> should be > >>> consolidated into one place.) > >> > >> Applied. What part of the firewall traversal did you find > particarly > >> useful? > > > > There were a few sentences that explained how, if everyone used > > the same ports for HIP, a firewall could trust that all use of > > those ports was HIP and could permit that traffic through the > > firewall. > > The port for the host inside the firewall can be emphemeral and for > the host outside of the firewall it is always 50500. I don't > think it is > necessary to require that both ports are 50500. Agreed. -d _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 08 06:17:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwbXS-0004pl-7Y; Fri, 08 Jun 2007 06:17:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0Lh-000140-FE; Tue, 29 May 2007 07:58:49 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht0Le-0005YR-VY; Tue, 29 May 2007 07:58:49 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 564FD1C00DF; Tue, 29 May 2007 13:58:46 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 46B2D1C00DD; Tue, 29 May 2007 13:58:44 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 39D2458EBBF; Tue, 29 May 2007 13:58:44 +0200 (CEST) Date: Tue, 29 May 2007 13:58:44 +0200 From: Stephane Bortzmeyer To: Pekka Savola Message-ID: <20070529115844.GA22682@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.6 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 X-Mailman-Approved-At: Fri, 08 Jun 2007 06:17:48 -0400 Cc: hipsec@ietf.org, ietf@ietf.org Subject: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, May 29, 2007 at 08:23:49AM +0300, Pekka Savola wrote a message of 187 lines which said: > 5) HIP wire format vs zone representation .. > I may me misunderstanding this, but doesn't that imply that the > authoritative DNS servers must implement Base16 and Base64 decoding support > so that they can convert from BaseXX to the on-the-wire format? First, there is traditionally no obligation, for a name server, to support the zone file format. Many name servers take their data from something else (a database, or a file with a different format). It is not even clear if it was a good idea to specify one zone file format in RFC 1035, since it is not "on the wire". Second, a name server already needs a specific parser for each resource record type. It does not seem it is different or more complicated to parse Base64 than it is to parse a LOC record. See the code in BIND's lib/dns/rdata/generic directory. Some resource record types already require knowledge of Base 64, such as CERT (RFC 4398) or DNSKEY (RFC 4034). For fun, I included here the LOC parsing code of nsd :-) /* * Parses a specific part of rdata. * * Returns: * * number of elements parsed * zero on error * */ uint16_t * zparser_conv_loc(region_type *region, char *str) { uint16_t *r; uint32_t *p; int i; int deg, min, secs; /* Secs is stored times 1000. */ uint32_t lat = 0, lon = 0, alt = 0; /* encoded defaults: version=0 sz=1m hp=10000m vp=10m */ uint8_t vszhpvp[4] = {0, 0x12, 0x16, 0x13}; char *start; double d; for(;;) { deg = min = secs = 0; /* Degrees */ if (*str == '\0') { zc_error_prev_line("unexpected end of LOC data"); return NULL; } if (!parse_int(str, &str, °, "degrees", 0, 180)) return NULL; if (!isspace(*str)) { zc_error_prev_line("space expected after degrees"); return NULL; } ++str; /* Minutes? */ if (isdigit(*str)) { if (!parse_int(str, &str, &min, "minutes", 0, 60)) return NULL; if (!isspace(*str)) { zc_error_prev_line("space expected after minutes"); return NULL; } ++str; } /* Seconds? */ if (isdigit(*str)) { start = str; if (!parse_int(str, &str, &i, "seconds", 0, 60)) { return NULL; } if (*str == '.' && !parse_int(str + 1, &str, &i, "seconds fraction", 0, 999)) { return NULL; } if (!isspace(*str)) { zc_error_prev_line("space expected after seconds"); return NULL; } if (sscanf(start, "%lf", &d) != 1) { zc_error_prev_line("error parsing seconds"); } if (d < 0.0 || d > 60.0) { zc_error_prev_line("seconds not in range 0.0 .. 60.0"); } secs = (int) (d * 1000.0 + 0.5); ++str; } switch(*str) { case 'N': case 'n': lat = ((uint32_t)1<<31) + (deg * 3600000 + min * 60000 + secs); break; case 'E': case 'e': lon = ((uint32_t)1<<31) + (deg * 3600000 + min * 60000 + secs); break; case 'S': case 's': lat = ((uint32_t)1<<31) - (deg * 3600000 + min * 60000 + secs); break; case 'W': case 'w': lon = ((uint32_t)1<<31) - (deg * 3600000 + min * 60000 + secs); break; default: zc_error_prev_line("invalid latitude/longtitude"); return NULL; } ++str; if (lat != 0 && lon != 0) break; if (!isspace(*str)) { zc_error_prev_line("space expected after latitude/longitude"); return NULL; } ++str; } /* Altitude */ if (*str == '\0') { zc_error_prev_line("unexpected end of LOC data"); return NULL; } if (!isspace(*str)) { zc_error_prev_line("space expected before altitude"); return NULL; } ++str; start = str; /* Sign */ if (*str == '+' || *str == '-') { ++str; } /* Meters of altitude... */ (void)strtol(str, &str, 10); switch(*str) { case ' ': case '\0': case 'm': break; case '.': if (!parse_int(str + 1, &str, &i, "altitude fraction", 0, 99)) { return NULL; } if (!isspace(*str) && *str != '\0' && *str != 'm') { zc_error_prev_line("altitude fraction must be a number"); return NULL; } break; default: zc_error_prev_line("altitude must be expressed in meters"); return NULL; } if (!isspace(*str) && *str != '\0') ++str; if (sscanf(start, "%lf", &d) != 1) { zc_error_prev_line("error parsing altitude"); } alt = (uint32_t) (10000000.0 + d * 100 + 0.5); if (!isspace(*str) && *str != '\0') { zc_error_prev_line("unexpected character after altitude"); return NULL; } /* Now parse size, horizontal precision and vertical precision if any */ for(i = 1; isspace(*str) && i <= 3; i++) { vszhpvp[i] = precsize_aton(str + 1, &str); if (!isspace(*str) && *str != '\0') { zc_error_prev_line("invalid size or precision"); return NULL; } } /* Allocate required space... */ r = alloc_rdata(region, 16); p = (uint32_t *) (r + 1); memmove(p, vszhpvp, 4); write_uint32(p + 1, lat); write_uint32(p + 2, lon); write_uint32(p + 3, alt); return r; } _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 12 15:50:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNx-0007zY-Go; Tue, 12 Jun 2007 15:50:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNs-0007m8-Oi; Tue, 12 Jun 2007 15:50:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyCNs-0001ig-Ed; Tue, 12 Jun 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5B4272AC78; Tue, 12 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyCNO-0005l1-44; Tue, 12 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-08.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-08.txt Pages : 106 Date : 2007-6-12 This memo specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie- Hellman key exchange, using public-key identifiers from a new Host Identity name space for mutual peer authentication. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the- middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper layer protocols, such as TCP and UDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-12120911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-12120911.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Tue Jun 12 15:50:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCO9-0008RV-KZ; Tue, 12 Jun 2007 15:50:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNt-0007ni-4W; Tue, 12 Jun 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyCNs-0001im-Oj; Tue, 12 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 98BD917600; Tue, 12 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyCNO-0005l7-5R; Tue, 12 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-esp-06.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Using ESP transport format with HIP Author(s) : P. Jokela, et al. Filename : draft-ietf-hip-esp-06.txt Pages : 37 Date : 2007-6-12 This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-esp-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-esp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-esp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-6-12121038.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-esp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-esp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-12121038.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Wed Jun 13 10:29:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTqL-0000n7-Ik; Wed, 13 Jun 2007 10:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTqK-0000lr-GI for hipsec@lists.ietf.org; Wed, 13 Jun 2007 10:29:04 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyTqG-00078X-Md for hipsec@lists.ietf.org; Wed, 13 Jun 2007 10:29:04 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0E3A12D03; Wed, 13 Jun 2007 17:29:00 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A96FB2CF5; Wed, 13 Jun 2007 17:28:57 +0300 (EEST) Date: Wed, 13 Jun 2007 17:28:57 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing Subject: RE: [Hipsec] hip-nat-traversal-02-pre5 In-Reply-To: <093e01c7a794$d2ccbd20$c2f0200a@amer.cisco.com> Message-ID: References: <093e01c7a794$d2ccbd20$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org, 'Jonathan Rosenberg' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 5 Jun 2007, Dan Wing wrote: (sorry, response quite late again) >>>> Your assumption is correct assuming you mean relay instead of >>>> rendezvous server. Should it communicate it? >>> >>> Yes, at the same time you communicate the IP address, because you >>> can't assume the remote peer will be able to obtain the expected UDP >>> port --- the NAT may very well have given a different host that UDP >>> port already. >> >> The current draft assumes that the same port (50500) of the relay can >> be used by several hosts. The multiplexing is done based on the ESP SPI >> numbers and not the UDP port. > > But you can only accomplish that multiplexing after you're doing > IPSec ESP -- HIP runs before that, I think? I didn't get this. We have two kinds of packets that the relay server can forward. It can forward either HIP or ESP packets: * IP(UDP(HIP)) * IP(UDP(ESP(TCP or UDP))) ^ ^ | | +---+---- ESP forwarding/multiplexing can be done here. Either using IP addresses and ports, or ESP SPI number. I am proposing the latter. This should be clarified in the draft. >>>> Actually, this brought to my mind a related idea that I did not >>>> include in the draft yet. The registration phase could be identical >>>> to the connectivity test phase, except there not may be a relay >>>> available yet and the packets are carrying REG parameters. In this >>>> case, the packets would also carry the locator information of the >>>> initiator to the relay. >>> >>> That sounds similar to what ICE does. Actually, it may be a better idea to treat HIP associations with relay registration differently from others. When a relay client initially registers to relay, the overhead of connectivity tests would be negligible. However, the overhead more critical with handovers. If connectivity tests have to be done before a handover, it will increase the latency and this will not be nice for e.g. TCP. Or is there any good reason to do connectivity tests with a publicly-addressable relay server? The only good reason would be to get rid of the UDP encapsulation, but this would happen at the cost of a slower handover. Removal of the UDP encapsulation has some additional problems when the other peer is still behind NAT, so I am not sure if it is a good idea. Currently I would just propose to keep the registration text as it is and add a description that relay HIP associations do not require connectivity tests. >> How would you design the protocol based on offer/answer? > > offer: > - gather candidate IP addresses and UDP ports > - send those candidate IP addresses and UDP ports to your intended > HIP peer, via your rendezvous server. > > answer: > - have your intended HIP peer gather its candidate IP addresses > and UDP ports > - have your intended HIP peer send its candidate IP addresses and > UDP ports back to the offerer, via your rendezvous server. > > As soon as one side learns the candidate addresses of the other side > it can immediately begin doing connectivity checks. For HIP, you > might want to map your two HIT identifiers directly into the STUN > username field; you are already communicating your HIT to your > intended peer anyway. > >> Could illustrate with a simple flow diagram? Please also illustrate the >> handover. > > Offer NAT STUN server rendezvous server Answerer > | | | | | > 1 |---------------->| | | > 2 |<----------------| | | > 3 |-------------------------------->| | > 4 | | | |------------------->| > 5 | X<=============================================| > 6 | | | |<-------------------| > 7 |<--------------------------------| | > 8 |=====================================================>| > 9 |<=====================================================| > 10 |<=====================================================| > 11 |=====================================================>| 12 |<================= base exchange =======================>| ? > 11. STUN response is sent, and received by the answerer. It > now knows it has bi-directional communication with the > offerer. 12. Run base exchange over the UDP tunnel created by ICE? A reason why this is not defined like depicted above is to reduce RTT time. A minor benefit is that we save some RTT by piggypacking the port allocation to RVS registration (this is actually missing from the above picture for the answerer). The rendezvous server is required anyway, so why not? A major benefit is for handovers. When a mobile client moves, it does not need to do connectivity tests with the rendezvous server (see above my comment on handling rendezvous registration and connectivity a little bit differently). A minor reason is that we save some RTT by sending the first base exchange packet (I1) already in step 3. When the rendezvous is on the path, we save more RTT because we don't have to wait for base exchange until step 12. However, your proposal is better when the rendezvous server is far from the path between offerer and answerer because step 8 can be done (and should be done) without the rendezvous. In the current draft, R1 and I2 messages have to be forwarded through the relay because they may contain also ESP relay information. >> To me, the current draft is ICE fitted to the HIP protocol. > > There are significant differences; for example, ICE doesn't use IP > addresses as identifiers, because they are rendered meaningless with > overlapped IP address space (192.168.1.2, commonly given to everyone's > PC behind a Linksys/DLink/Belkin NAT). The mechanism in > HIP-NAT-TRAVERSAL seems to use IP addresses as identifiers. I did not still understand this comment. We probably have some sort of terminology mismatch here. If I understood correctly, ICE used username and password as the identifier. In HIP, the identifier is HIT, not IP. HITs are present in all HIP control packet headers. IP address are in IP packet headers, and also in HIP LOCATOR parameters (to inform the peer on all available locators). >> We have already a base exchange protocol and mobility extensions for >> non-natted environments, so it made sense to me to reuse the existing >> mechanism for NATted environments. For example, registration is a base >> exhange and the connectivity test is almost the same as a mobility >> handover. > > I agree reusing those is useful; I think more of the stuff that's in ICE > -- using an identifier other than IP address and proving proof of some > private information (exchanged via the rendezvous server between the > intended peers) would go a long way towards thwarting accidental > association with the wrong peer and towards thwarting attackers > interfering with handover. Yes. >> A separate protocol mechanism would introduce larger >> code base for implementations which is not very nice. > > Understood. However, we need to tease apart the differences between > what ICE is doing -- successfully on the Internet -- and what you're > proposing to do, and make sure HIP's NAT traversal will be as successful > when HIP needs to traverse non-HIP-aware NATs. Saving a few hundred > lines of code isnn't the desired goal; successful operation on today's > Internet is the desired goal. Saving RTT time is very important for successful user experience although I like your idea of plugging the NAT traversal as a separate component below HIP layer from engineering point of view. It could actually allow even more software reuse. > We must be talking past each other. > > If the hosts are behind the same NAT, they're going to get different > source UDP ports -- that's how every sane NAT functions. There can be > no successful, properly operating NAT that does port overloading -- it > doesn't work. That's why it's a MUST NOT in the BEHAVE UDP > specification. Yes, I think there was just a misunderstanding here. See below. >> When a host is behind NAT(s), the NAT(s) will translate the port. The >> host can discover the translated port number (reflexive relay locator) >> from the relay or during connectivity tests (reflexive peer locator). >> These reflexive addresses are given/discovered by the peer and the peer >> will use them to communicate with the host. >> >> It does not really matter whether the NAT preserves the port or not as >> the translated port is sent to peer. If there is something said >> unclearly in the document about this, please give specific pointers to >> the text and/or suggestions to corrections. > > Yes, the document states that the source UDP port 50500 is retained when > the UDP port traverses the NAT. Specifically: > > 3.1. Port Number Selection > > The end-hosts need a fixed transport layer port number to be able to > communicate with each other. The end-hosts MUST accept incoming HIP > and ESP traffic arriving at UDP port HIPPORT (future extensions may > use the same port number for TCP). > > If an end-host already registers with a rendezvous server, I don't see the > need for assignment of a fixed UDP port. Furthermore, if the end host does > allocate HIPPORT for use by HIP and that host is behind a NAT, then from the > perspective of all the other hosts on the Internet, the NAT _is_ the end > host. And of course if that NAT has already allocated HIPPORT to another > host behind the same NAT, the NAT cannot also allocate the same HIPPORT to > this (new) host. > > Thus, you need to communicate both an IP address and UDP port to the > rendezvous server. I think I got your point now, but the fixed port number is still required for the relay server. The fixed port number is required at the relay when the a relay client registers through its NAT to a publicly-addressable relay server. In short, the fixed port number requirement applies only to the relay server, not to the end-hosts. This should be changed in the draft. (I believe there is no need to use the fixed port number when the hosts are behind the same NAT since they can talk directly over IP) > Section 3.2: > ... > When the ESP relay registration was successful, the relay server uses > the source IP address and port HIPPORT of the R2 packet to relay ESP > traffic with the client. > ... > > Same problem -- the relaying agent (on the Internet) can't send traffic to > HIPPORT; it needs to send traffic to whatever UDP port was used to > communicate with the relay agent. It sends traffic _from_ HIPPORT. This needs to explained better in the draft. > One new comment I have, is text in section 5, which reads: > > When the Initiator is behind a firewall, the NAT traversal mechanisms > described in Section 3 depend on the ability to initiate > communication via UDP to the destination port HIPPORT from arbitrary > source ports and to receive UDP response traffic from that port to > the chosen source port. If the Initiator is behind a firewall that > does not support "UDP connection tracking", the NAT traversal > mechanisms described in Section 3 can still be supported, if the > firewall allows permanently inbound UDP traffic from the port HIPPORT > and destined to arbitrary source IP addresses and UDP ports. > > It should be noted, though, that if there is a NAT between the hosts and the > firewall, the use of the source HIPPORT won't be useful: > > > PC ---\ > PC ---\\ > PC ----++--[NAT]----[firewall] > PC ---// > PC ---/ > > because if all those PCs use the source HIPPORT, only the first one to cause > a UDP packet to traverse the NAT has any chance of getting the NAT to map > that same HIPPORT to the NAT's source UDP port. The other 4 PCs will lose. Only relays need the fixed port number, not the end-hosts. The relay sees the outernmost NAT IP address and port number, and uses it to send HIP control packets the correct PC. Do you see any harm in using a fixed port number also at the end-hosts even though the NAT will translate it? >>> If so, what is the purpose of FROM_PEER? >> >> To discover the reflexive peer locators. See step 4 in >> section section 3.4. > > Ok. I'm still unclear on its overall purpose, but I did find the following > in section 3.4: > > If the FROM_PEER and TO_PEER do not > match, the Responder may be behind a "p2p-unfriendly" NAT > [I-D.ietf-behave-p2p-state]. This means the NAT does not preserve > the transport locator of the Responder when it communicates with > multiple hosts. This kind of address-port pair is referred as "peer > reflexive transport locator". The Initiator MUST store the transport > address for later processing. The Initiator MUST transition the > corresponding locator pair to ACTIVE state. > > and in section 2 (introduction): > > In contrast, the relay service > relays all HIP control packets because p2p-unfriendly NAT devices > drop the packets otherwise [I-D.ietf-behave-p2p-state]. > > With ICE, there is one and only one case where a relay is needed. That is > when _BOTH_ peers are behind p2p-unfriendly NATs. If only one of the peers > is behind a p2p-unfriendly NAT, a relay is not needed. The same applies to the current draft. Please suggest more detailed clarification if possible. >> I still remain unconvinced that the optimization is worth it. > > That's fine. As I said, it isn't a big deal; it can be done later without > interoperability problems, too, so it's safe to defer it until there is a > need to reduce keepalive traffic by half. Ok. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 13 21:17:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HydxR-0008LH-KQ; Wed, 13 Jun 2007 21:17:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HydxQ-0008It-HT for hipsec@ietf.org; Wed, 13 Jun 2007 21:17:04 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HydxP-0003Nj-9d for hipsec@ietf.org; Wed, 13 Jun 2007 21:17:04 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HydxO-0005Tw-2j for hipsec@ietf.org; Wed, 13 Jun 2007 21:17:02 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <9E4DE0FA-F00D-451C-9C25-6154FEF94C54@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: HIP From: Philip Matthews Date: Wed, 13 Jun 2007 21:17:01 -0400 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Hipsec] A question about the HIP checksum X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org I have a question about the HIP checksum. What is the reasoning behind having the HIP checksum cover a pseudo- header containing the IP addresses? For TCP and UDP, the stated reason to have the checksum cover a pseudo-header is to guard against mis-delivered packets; this reason doesn't seem to apply in HIP since the cryptographic checks provide much stronger security. Naively, having the HIP checksum cover a pseudo-header just seems to make things more complex, since this forces checksum re-computation at middleboxes etc. Am I missing something? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 14 18:35:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxuT-0005oJ-Gh; Thu, 14 Jun 2007 18:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxuS-0005o8-7N for hipsec@ietf.org; Thu, 14 Jun 2007 18:35:20 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyxuN-0003XJ-UH for hipsec@ietf.org; Thu, 14 Jun 2007 18:35:20 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l5EMZF8V020049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 14 Jun 2007 17:35:15 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l5EMZEPW013511; Thu, 14 Jun 2007 17:35:14 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l5EMZE6P013486; Thu, 14 Jun 2007 17:35:14 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.46]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 15:35:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] A question about the HIP checksum Date: Thu, 14 Jun 2007 15:35:13 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040494B2@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <9E4DE0FA-F00D-451C-9C25-6154FEF94C54@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] A question about the HIP checksum Thread-Index: AceuIbseUJ83LRj8S4KbsZGce6E/vQAsQxEg From: "Henderson, Thomas R" To: "Philip Matthews" X-OriginalArrivalTime: 14 Jun 2007 22:35:14.0530 (UTC) FILETIME=[46AB9C20:01C7AED4] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 > Sent: Wednesday, June 13, 2007 6:17 PM > To: HIP > Subject: [Hipsec] A question about the HIP checksum >=20 > I have a question about the HIP checksum. >=20 > What is the reasoning behind having the HIP checksum cover a pseudo-=20 > header containing the IP addresses? Philip, There was discussion of this several years ago, such as archived in the following two posts: http://www1.ietf.org/mail-archive/web/hipsec/current/msg00099.html http://www1.ietf.org/mail-archive/web/hipsec/current/msg00104.html - Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 18 15:49:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NDr-0005Xz-Ax; Mon, 18 Jun 2007 15:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NDp-0005Xu-UR for hipsec@ietf.org; Mon, 18 Jun 2007 15:49:09 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0NDn-0001Ay-T6 for hipsec@ietf.org; Mon, 18 Jun 2007 15:49:09 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0NDl-0008Ib-1u; Mon, 18 Jun 2007 15:49:05 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69DA200E-6FBA-4965-928E-5FD4D585F79E@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 18 Jun 2007 15:49:02 -0400 To: HIP WG X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Alan Johnston , Eric Cooper , hipsec-rg@listserv.cybertrust.com Subject: [Hipsec] I-D on using HIP for P2PSIP: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks: I would like to call your attention to a draft that was just submitted to the P2PSIP working group. This document proposes to use HIP as the basis in forming a P2PSIP overlay network. The draft is a high-level draft that is trying to sell the P2PSIP group on the idea of using HIP, rather than a detailed design. So we simply sketch the ideas in a broad fashion, rather than giving precise details. However, the authors still feel the draft will likely be of interest to the HIP community. In particular, what is likely of greatest interest are the four HIP extensions that the draft proposes: * Defining how to route HIP packets though intermediate peers in an overlay; * Adding a new HIP packet type (which we call the Data packet) to transport upper-layer protocols in the overlay when the transmission path goes through one or more intermediate peers; * Extending the procedures for establishing a HIP association to the case where a peer wants to join an overlay; * Proposing alternative transport stack for protocols where running over ESP is undesirable (e.g. Secure RTP transport of voice packets). The authors would be very interested in getting feedback from the HIP community on these proposed extensions. From a HIP prospective, what is interesting is that this approach provides a motivation for people to use HIP, because it is using HIP in a "closed" system: a peer-to-peer overlay. The document was just submitted on the weekend, and had not yet appeared in archives when this was written. Until it does, you can get a copy at: http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- hop-00.txt or an HTML version at: http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- hop-00.htm - Philip [I am cross-posting this to the HIP RG list, but after discussion with Gonzalo, we think that the HIP WG mailing list is the best place to discuss the details of the proposed HIP extensions. However, if you have any general comments on the suitability of HIP for P2PSIP, or general comments on the draft, then those comments are best directed to the P2PSIP list.] _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 18 22:13:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0TDV-0000pC-OP; Mon, 18 Jun 2007 22:13:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0TDU-0000p4-NI for hipsec@lists.ietf.org; Mon, 18 Jun 2007 22:13:12 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0TDT-0006Lx-Cr for hipsec@lists.ietf.org; Mon, 18 Jun 2007 22:13:12 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0TDS-0001j2-0l; Mon, 18 Jun 2007 22:13:10 -0400 In-Reply-To: References: <093e01c7a794$d2ccbd20$c2f0200a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A213FC4-3996-4ED1-BA6E-7CF0CCFCD70D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] hip-nat-traversal-02-pre5 Date: Mon, 18 Jun 2007 22:13:06 -0400 To: Miika Komu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org, 'Jonathan Rosenberg' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org I apologize for coming late to this discussion. See comments inline. - Philip On 13-Jun-07, at 10:28 , Miika Komu wrote: > >>> How would you design the protocol based on offer/answer? >> >> offer: >> - gather candidate IP addresses and UDP ports >> - send those candidate IP addresses and UDP ports to your intended >> HIP peer, via your rendezvous server. >> >> answer: >> - have your intended HIP peer gather its candidate IP addresses >> and UDP ports >> - have your intended HIP peer send its candidate IP addresses and >> UDP ports back to the offerer, via your rendezvous server. >> >> As soon as one side learns the candidate addresses of the other side >> it can immediately begin doing connectivity checks. For HIP, you >> might want to map your two HIT identifiers directly into the STUN >> username field; you are already communicating your HIT to your >> intended peer anyway. >> >>> Could illustrate with a simple flow diagram? Please also >>> illustrate the handover. >> >> Offer NAT STUN server rendezvous server Answerer >> | | | | | >> 1 |---------------->| | | >> 2 |<----------------| | | >> 3 |-------------------------------->| | >> 4 | | | |------------------->| >> 5 | X<=============================================| >> 6 | | | |<-------------------| >> 7 |<--------------------------------| | >> 8 |=====================================================>| >> 9 |<=====================================================| >> 10 |<=====================================================| >> 11 |=====================================================>| > > 12 |<================= base exchange =======================>| ? > >> 11. STUN response is sent, and received by the answerer. It >> now knows it has bi-directional communication with the >> offerer. > > 12. Run base exchange over the UDP tunnel created by ICE? First of all, I want to say that I basically agree with Dan. You want to have an offer/answer exchange. However, you do not need to actually include SDP in the HIP messages. It is fine to encode the details into HIP TLVs as you have done in your draft. Back in Prague, we discussed including the offer and answer in the I2 and R2 messages respectively. Thus the base exchange and offer/answer exchange happens at the same time. Why not go with this design? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 20 02:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tP2-0005Af-3R; Wed, 20 Jun 2007 02:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tP0-0005AY-D7 for hipsec@lists.ietf.org; Wed, 20 Jun 2007 02:10:50 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0tOy-0000bv-2l for hipsec@lists.ietf.org; Wed, 20 Jun 2007 02:10:50 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 350D52D1D; Wed, 20 Jun 2007 09:10:47 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A99112D1B; Wed, 20 Jun 2007 09:10:45 +0300 (EEST) Date: Wed, 20 Jun 2007 09:10:45 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Philip Matthews Subject: Re: [Hipsec] hip-nat-traversal-02-pre5 In-Reply-To: <8A213FC4-3996-4ED1-BA6E-7CF0CCFCD70D@magma.ca> Message-ID: References: <093e01c7a794$d2ccbd20$c2f0200a@amer.cisco.com> <8A213FC4-3996-4ED1-BA6E-7CF0CCFCD70D@magma.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org, 'Jonathan Rosenberg' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 18 Jun 2007, Philip Matthews wrote: Hi, > First of all, I want to say that I basically agree with Dan. You want to > have an offer/answer exchange. However, you do not need to actually > include SDP in the HIP messages. It is fine to encode the details into > HIP TLVs as you have done in your draft. Ok. Please tell if there is still something missing. > Back in Prague, we discussed including the offer and answer in the I2 > and R2 messages respectively. Thus the base exchange and offer/answer > exchange happens at the same time. Why not go with this design? I did not forget about this. I thought about it for long and decided to change it for two reasons. First, to retain similarity with the HIP mobility draft (no locators in R2). Second, I thought that it would be more useful to have a single mechanism to trigger the reachability/connectivity tests. The UPDATE with LOCATOR acts as the trigger, both after a base exchange and a handover. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 22 16:16:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pYN-0004Eq-NA; Fri, 22 Jun 2007 16:16:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1pYM-0004Eb-Qr for hipsec@lists.ietf.org; Fri, 22 Jun 2007 16:16:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1pYL-0002Ug-Eo for hipsec@lists.ietf.org; Fri, 22 Jun 2007 16:16:22 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2007 13:16:21 -0700 X-IronPort-AV: i="4.16,452,1175497200"; d="scan'208"; a="170488791:sNHT45510867" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5MKGKlP007175; Fri, 22 Jun 2007 13:16:20 -0700 Received: from dwingwxp (dhcp-128-107-102-52.cisco.com [128.107.102.52]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5MKGGka024395; Fri, 22 Jun 2007 20:16:16 GMT From: "Dan Wing" To: Date: Fri, 22 Jun 2007 13:16:16 -0700 Message-ID: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace1B0PJkTUJENkLRVaKURSQq/LOCgAAqSQw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2762; t=1182543380; x=1183407380; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20draft-tschofenig-hip-ice-00.txt=20 |Sender:=20; bh=NNS8dIbz7nZXaTPVZnRNbN6Cxmpw0hG1q4GqVU/+Z60=; b=jL27w/W8irOsOu44MjhA4+F2jzflIqLgNNe0znOnchMGuYLBE2tiYCgR/EQ6XvBpwnMhMDdH 1k/bCe38lw5TeImwc6PR4sQjZ1utqb6i2AEp+d5a9eiD1SB0P2hPdsw7; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: simon.schuetz@netlab.nec.de Subject: [Hipsec] draft-tschofenig-hip-ice-00.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org This document explains how we see ICE and HIP could work together. Comments welcome. -d > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Utilizing Interactive Connectivity > Establishment (ICE) for the Host Identity Protocol (HIP) > Author(s) : H. Tschofenig, D. Wing > Filename : draft-tschofenig-hip-ice-00.txt > Pages : 22 > Date : 2007-6-22 > > > This document describes how the Interactive Connectivity > Establishment (ICE) methodology can be used for the Host Identity > Protocol (HIP) to determine whether end-to-end communication is > possible. ICE makes use of the Session Traversal Utilities for NAT > (STUN) protocol in addition to mechanisms for checking connectivity > between peers. After running the ICE the two HIP end > points will be > able to communicate directly or through a relay via Network Address > Translators (NATs), Network Address and Port Translators > (NAPTs) and > firewalls . > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of > the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-tschofenig-hip-ice-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-tschofenig-hip-ice-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 22 21:10:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1u8W-00068I-44; Fri, 22 Jun 2007 21:10:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1u8U-00068A-OU for hipsec@lists.ietf.org; Fri, 22 Jun 2007 21:09:58 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1u8U-000442-Bi for hipsec@lists.ietf.org; Fri, 22 Jun 2007 21:09:58 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I1u8T-0000gT-25; Fri, 22 Jun 2007 21:09:57 -0400 In-Reply-To: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> References: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E115CCB-798C-474E-B78E-223D06311AF0@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] draft-tschofenig-hip-ice-00.txt Date: Fri, 22 Jun 2007 21:09:57 -0400 To: Dan Wing , Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org A few questions/comments on this draft: 1) Can you explain in more detail how you see the ICE attributes being encoded? 2) Another way to distinguish STUN messages from HIP is by using bit 31 of the first 32-bit quadword. In HIP, this must always be 1. In STUN, this must always be 0, since STUN messages must always be a multiple of 4 bytes. 3) It seems weird to me to use the ufrag stuff of ICE (= a random endpoint identifier) when HIP already has HITs. - Philip On 22-Jun-07, at 16:16 , Dan Wing wrote: > This document explains how we see ICE and HIP could work together. > Comments > welcome. > > -d > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Utilizing Interactive Connectivity >> Establishment (ICE) for the Host Identity Protocol (HIP) >> Author(s) : H. Tschofenig, D. Wing >> Filename : draft-tschofenig-hip-ice-00.txt >> Pages : 22 >> Date : 2007-6-22 >> >> >> This document describes how the Interactive Connectivity >> Establishment (ICE) methodology can be used for the Host Identity >> Protocol (HIP) to determine whether end-to-end communication is >> possible. ICE makes use of the Session Traversal Utilities for >> NAT >> (STUN) protocol in addition to mechanisms for checking >> connectivity >> between peers. After running the ICE the two HIP end >> points will be >> able to communicate directly or through a relay via Network >> Address >> Translators (NATs), Network Address and Port Translators >> (NAPTs) and >> firewalls . >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-tschofenig-hip-ice-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-tschofenig-hip-ice-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 22 21:48:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ujr-0002fQ-OX; Fri, 22 Jun 2007 21:48:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ujq-0002da-2q for hipsec@ietf.org; Fri, 22 Jun 2007 21:48:34 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1ujo-00076s-Gy for hipsec@ietf.org; Fri, 22 Jun 2007 21:48:33 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1I1ujn-0006Ld-LX; Fri, 22 Jun 2007 21:48:31 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <498F4BCB-9FD7-4F0D-813A-289C6D9C0656@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 22 Jun 2007 21:48:31 -0400 To: Miika Komu , Dan Wing , Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: HIP WG Subject: [Hipsec] ICE-for-HIP design choice: STUN or HIP? X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Now that there are two competing proposals for how to do ICE-for-HIP: http://tools.ietf.org/id/draft-ietf-hip-nat-traversal-01.txt and http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt it seems to me that it would be good to step back for a moment and have a discussion on some basic design choices. Discussing these individually would help the design process, in my opinion. One of these basic questions is whether to use STUN or an enhanced version of HIP for binding discovery and for connectivity checks. Miika's document proposes to use an enhanced version of HIP, while Hannes's document proposes to use STUN. Here is what I see as being the pros and cons of the two approaches: STUN: + Protocol is already defined and deployed. + The usage of STUN in ICE is already defined. - STUN has to be run over the same port as HIP, and the only way to distinguish the two protocols is by header inspection. There are a few bits of difference, but this is not exactly a beautiful design. - HIP-aware NATs must be able to do a fairly complete decode of STUN packets. (more on this below) Enhanced HIP: + Fits much more naturally with the rest of HIP. - Requires more work to define how ICE works. + No weird header inspection + Natural behavior at HIP-aware NATs. - Not currently defined ? Not currently deployed Let me discuss two of these in more detail. The first is the question of deployment. STUN is currently deployed today, so there are STUN servers that a HIP node could use. But is this really important? If we build enhanced HIP functionality into HIP and into RVSes, then I think there will always be a public server around that a HIP node could use to discover its reflexive address. The rest of this message discusses the question of how to handle HIP- aware NATs. With a HIP-aware NAT, we could get rid of the UDP encapsulation, and run HIP directly over IP. This, in my opinion, is an important design goal. If HIP is successful, then we should assume that NATs will be upgraded to understand HIP, and this will allow us to get rid of the irritating UDP encapsulation. To understand how this might work, we need to agree how a HIP-aware NAT would operate. Let's consider a HIP packet sent from node X which is behind a HIP- aware NAT to a node Y which is in the public Internet, and a response coming back from Y to X. [For now, I am ignoring the fact that most of the traffic on HIP associations is actually ESP traffic and not HIP traffic. I will discuss this below.] Let's look at the IP addresses and HITs in the packets as they flow through the NAT. At X At N At Y src: (X-IP, X-HIT) (N-IP, X-HIT) dst: (Y-IP, Y-HIT) ------------> (Y-IP, Y-HIT)----------> src: (X-IP, X-HIT) (Y-IP, Y-HIT) dst: (Y-IP, Y-HIT) <--------- (N-IP, X-HIT) At the top, X sends a packet with its (private) IP address and Y's public IP address in the IP header, and its HIT and Y's HII at the HIP layer. At the NAT, X's private IP address is replaced by N's public address. When Y replies, it sends to N's public address, which gets replaced by the NAT with X's private address. Thus the NAT stores: mapping entry: X-HIT --> X-IP (i.e., the node identified by HIT X-HIT is at IP address X-IP) filtering entry: X-HIT <-- Y-HIT (i.e., the node identified by HIT X-HIT can receive packets from the node identified by Y-HIT). All this works very well if we use enchanced HIP. But how does this work if we use STUN instead? In this case, the packet would consist of a STUN message riding directly over IP (but where the IP protocol field would specify HIP rather than STUN). In order for the NAT to create the appropriate bindings, the STUN message would need to contain the source and destination HITs somewhere in the message. The only place to carry these in STUN is in some STUN attribute. So this means that the NAT has to be able to do a fairly complete parse of a STUN message. Requiring a HIP-aware NAT to do a fairly complete parse of a STUN message concerns me a bit. It seems quite unnatural to me. Comments? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 11:46:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I27oV-0001uu-Sv; Sat, 23 Jun 2007 11:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I27oU-0001tk-O2 for hipsec@lists.ietf.org; Sat, 23 Jun 2007 11:46:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I27oS-0003Wp-N5 for hipsec@lists.ietf.org; Sat, 23 Jun 2007 11:46:14 -0400 Received: (qmail invoked by alias); 23 Jun 2007 15:46:10 -0000 Received: from p54984EE0.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.78.224] by mail.gmx.net (mp019) with SMTP; 23 Jun 2007 17:46:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/9nE4fiQ792M2lxkT4BKlcsM2NVM25/UMn0iAGuO zaiSfMkpeKLisc Message-ID: <467D4042.2050805@gmx.net> Date: Sat, 23 Jun 2007 17:46:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [Hipsec] draft-tschofenig-hip-ice-00.txt References: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> <7E115CCB-798C-474E-B78E-223D06311AF0@magma.ca> In-Reply-To: <7E115CCB-798C-474E-B78E-223D06311AF0@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: hipsec@lists.ietf.org, Hannes Tschofenig X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Phillip, Philip Matthews wrote: > A few questions/comments on this draft: > > 1) Can you explain in more detail how you see the ICE attributes being > encoded? > Currently, we went for a really simple approach: We just take the same format as in ICE and dump them into an attribute for exchange in HIP. Maximum code reuse was the goal. One can obviously change the encoding of the attribute. BUT the encoding of the candidates is not really important thing. > 2) Another way to distinguish STUN messages from HIP is by using bit > 31 of the first 32-bit quadword. > In HIP, this must always be 1. In STUN, this must always be 0, > since STUN messages > must always be a multiple of 4 bytes. Thanks. We can add that as well. > > 3) It seems weird to me to use the ufrag stuff of ICE (= a random > endpoint identifier) > when HIP already has HITs. Good observation. I have to think about it if it makes sense to change that. Dan will respond to your other mail. Ciao Hannes > > - Philip > > > On 22-Jun-07, at 16:16 , Dan Wing wrote: > >> This document explains how we see ICE and HIP could work together. >> Comments >> welcome. >> >> -d >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Utilizing Interactive Connectivity >>> Establishment (ICE) for the Host Identity Protocol (HIP) >>> Author(s) : H. Tschofenig, D. Wing >>> Filename : draft-tschofenig-hip-ice-00.txt >>> Pages : 22 >>> Date : 2007-6-22 >>> >>> >>> This document describes how the Interactive Connectivity >>> Establishment (ICE) methodology can be used for the Host Identity >>> Protocol (HIP) to determine whether end-to-end communication is >>> possible. ICE makes use of the Session Traversal Utilities for NAT >>> (STUN) protocol in addition to mechanisms for checking connectivity >>> between peers. After running the ICE the two HIP end >>> points will be >>> able to communicate directly or through a relay via Network Address >>> Translators (NATs), Network Address and Port Translators >>> (NAPTs) and >>> firewalls . >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in >>> the body of >>> the message. >>> You can also visit >>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then >>> "get draft-tschofenig-hip-ice-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-tschofenig-hip-ice-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant >>> mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 12:26:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I28R1-0000Db-PD; Sat, 23 Jun 2007 12:26:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I28R0-0000DW-83 for hipsec@lists.ietf.org; Sat, 23 Jun 2007 12:26:02 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I28Qy-0005zO-W1 for hipsec@lists.ietf.org; Sat, 23 Jun 2007 12:26:02 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2007 09:26:00 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC/mfEarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,455,1175497200"; d="scan'208"; a="497119015:sNHT23120490" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5NGQ07l030730; Sat, 23 Jun 2007 09:26:00 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5NGPxXH019430; Sat, 23 Jun 2007 16:25:59 GMT From: "Dan Wing" To: "'Hannes Tschofenig'" , "'Philip Matthews'" Subject: RE: [Hipsec] draft-tschofenig-hip-ice-00.txt Date: Sat, 23 Jun 2007 09:25:58 -0700 Message-ID: <04b201c7b5b3$2f1ea760$78a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <467D4042.2050805@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace1raB/5KaUJ7NZSbegI7NyrjiOggABXlng DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=270; t=1182615960; x=1183479960; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Hipsec]=20draft-tschofenig-hip-ice-00.txt |Sender:=20; bh=93Hs+uabLQIClvKk70Tzwf5BPHfhKfLLSHtmk4lVzd8=; b=srJx85/+mbMxXR1rZHWsCGS2g8frWC67X7D/tkDRWWZ0/nMNbGZT/X7zR2bXgfDgYmX9mPDp SmL3ZTmllGsrHUkW+ziMg26eU2+Z7JsfgPtjx6uRvh1sOepgFyAaeYxN; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: hipsec@lists.ietf.org, 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > > 3) It seems weird to me to use the ufrag stuff of ICE (= a random > > endpoint identifier) > > when HIP already has HITs. > > Good observation. I have to think about it if it makes sense > to change that. stick the HIT into the USERNAME, then. -d _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 13:31:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I29Sc-00010M-9q; Sat, 23 Jun 2007 13:31:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I29Sb-00010G-69 for hipsec@ietf.org; Sat, 23 Jun 2007 13:31:45 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I29SZ-00052z-Fc for hipsec@ietf.org; Sat, 23 Jun 2007 13:31:45 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 23 Jun 2007 10:31:43 -0700 X-IronPort-AV: i="4.16,455,1175497200"; d="scan'208"; a="170870474:sNHT56421738" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5NHVgaq030733; Sat, 23 Jun 2007 10:31:42 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5NHVdmo023831; Sat, 23 Jun 2007 17:31:39 GMT From: "Dan Wing" To: "'Philip Matthews'" , "'Miika Komu'" , "'Hannes Tschofenig'" Date: Sat, 23 Jun 2007 10:31:39 -0700 Message-ID: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <498F4BCB-9FD7-4F0D-813A-289C6D9C0656@magma.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace1OJz9LLvUaOkZTTCkz15i9VJjSgAfiKBA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8090; t=1182619903; x=1183483903; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20ICE-for-HIP=20design=20choice=3A=20STUN=20or=20HIP? |Sender:=20; bh=TcC+pq1+DOzY/wgft6hyD7x1/4AXeXUgDtZVBsnG8cw=; b=pOFTflZr3DVEiJPTdC+zHj85Jqi1mr3rmhPimQwtN5lS4b+LgrhUMWTkpKZ+fN45Uh2+xaO0 B1+2abYZzrsfKO+cckCNGpTCtsqNcNYu+hjEVEsEBg+H7BBhkSRVyJaV+HbvjMItA8ESQ/3r/a N/Fp5SWTRDxmd76Muvl053rQw=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: 'HIP WG' Subject: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org The important difference with draft-tschofenig-hip-ice isn't the encoding on-the-wire. Rather, the important difference is performing ICE. Those steps are: Initiator: * gather candidate addresses * send candidate addresses to remote peer (terminator) via a rendezvous protocol (HIP, in this case; SIP in the traditional case of ICE) Terminator: * gather its own candidate addresses * perform connectivity checks with the remote peer (initiator) to find a functional path to the initiator * send candidate addresses to remote peer (initiator) via a rendezvous protocol (HIP) Initiator: * perform connectivity checks with the remote peer (terminator) * prioritize successful checks and determine which path is preferred (for example: avoid UDP encapsulation, take a path over only HIP-aware NATs if that's desirable, avoid NATs and take direct path, etc.). This choice is communicated to the remote peer (terminator), so it can make the same choice so bi-directional traffic can be assured (which is necessary to keep all the NATs open). Encoding: The connectivity checks need to be done using the same encapsulation and protocol that HIP and IPsec will subsequently use for their communication between the two peers. There are two cases: * HIP-over-UDP. Here, it makes sense to use STUN-over-UDP for those checks. * HIP directly over IP. Here, I concur with your email that it may be useful to perform connectivity checks using HIP itself. However, HIP would need encode much of the same information that STUN encodes into HIP TLVs; thus, an opaque object that contains a STUN message could make sense for the non-UDP HIP-over-IP case. Failure to encode those same parameters and failure to do the same steps as ICE will cause HIP's legacy NAT traversal to fail. But if we step back slightly it becomes apparent that non-HIP protocols would benefit from this same encoding -- NSIS comes immediately to mind (it needs to also work with non-NSIS-aware NATs). MIP (Mobile IP) comes to mind, as well (it would be useful to make sure you have connectivity before you switch to a new IP address, otherwise you won't be successful). Two other things in your email I'm not worried about: (a) HIP-aware NATs having to parse the STUN messages and (b) demultiplexing STUN and HIP. There are no HIP-aware NATs that I'm aware of, so there isn't an installed base of devices or software. If there is sufficient value in multiplexing STUN and HIP over the same UDP port, and someone wants to build a HIP-aware NAT, they can incur the slight difficulty in pulling a HIT out of a STUN message. This is perhaps 20 lines of code. Demultiplexing STUN and HIP is 3-4 lines of code, and has no false positives (where the demultiplexing fails). That said, I would really like to first concentrate on the *steps* involved in ICE, and how to make them work with HIP. Because that must first be agreed upon before we can reasonably discuss HIP parameter encoding. -d > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Friday, June 22, 2007 6:49 PM > To: Miika Komu; Dan Wing; Hannes Tschofenig > Cc: HIP WG > Subject: ICE-for-HIP design choice: STUN or HIP? > > Now that there are two competing proposals for how to do ICE-for-HIP: > http://tools.ietf.org/id/draft-ietf-hip-nat-traversal-01.txt > and > > http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt > it seems to me that it would be good to step back for a moment and > have a discussion on some basic design choices. Discussing these > individually would help the design process, in my opinion. > > One of these basic questions is whether to use STUN or an enhanced > version of HIP for binding discovery and for connectivity checks. > Miika's document proposes to use an enhanced version of HIP, while > Hannes's document proposes to use STUN. > > Here is what I see as being the pros and cons of the two approaches: > > STUN: > + Protocol is already defined and deployed. > + The usage of STUN in ICE is already defined. > - STUN has to be run over the same port as HIP, and the only way to > distinguish the two protocols is by header inspection. There are a > few bits of difference, but this is not exactly a beautiful design. > - HIP-aware NATs must be able to do a fairly complete decode of STUN > packets. (more on this below) > > Enhanced HIP: > + Fits much more naturally with the rest of HIP. > - Requires more work to define how ICE works. > + No weird header inspection > + Natural behavior at HIP-aware NATs. > - Not currently defined > ? Not currently deployed > > Let me discuss two of these in more detail. > > The first is the question of deployment. STUN is currently deployed > today, so there are STUN servers that a HIP node could use. But is > this really important? If we build enhanced HIP functionality into > HIP and into RVSes, then I think there will always be a > public server > around that a HIP node could use to discover its reflexive address. > > The rest of this message discusses the question of how to handle HIP- > aware NATs. With a HIP-aware NAT, we could get rid of the UDP > encapsulation, and run HIP directly over IP. This, in my opinion, is > an important design goal. If HIP is successful, then we > should assume > that NATs will be upgraded to understand HIP, and this will allow us > to get rid of the irritating UDP encapsulation. > > To understand how this might work, we need to agree how a HIP-aware > NAT would operate. > Let's consider a HIP packet sent from node X which is behind a HIP- > aware NAT > to a node Y which is in the public Internet, and a response coming > back from Y to X. > [For now, I am ignoring the fact that most of the traffic on HIP > associations > is actually ESP traffic and not HIP traffic. I will discuss > this below.] > > Let's look at the IP addresses and HITs in the packets as they flow > through the NAT. > At X At N At Y > src: (X-IP, X-HIT) (N-IP, X-HIT) > dst: (Y-IP, Y-HIT) ------------> (Y-IP, Y-HIT)----------> > > src: (X-IP, X-HIT) > (Y-IP, Y-HIT) > dst: (Y-IP, Y-HIT) <--------- > (N-IP, X-HIT) > > At the top, X sends a packet with its (private) IP address and Y's > public IP address > in the IP header, and its HIT and Y's HII at the HIP layer. > At the NAT, X's private IP address is replaced by N's public address. > When Y replies, it sends to N's public address, which gets replaced > by the NAT > with X's private address. > > Thus the NAT stores: > mapping entry: X-HIT --> X-IP (i.e., the node > identified by HIT > X-HIT is at IP address X-IP) > filtering entry: X-HIT <-- Y-HIT (i.e., the node > identified by HIT > X-HIT can receive packets from > the node > identified by Y-HIT). > > All this works very well if we use enchanced HIP. > > But how does this work if we use STUN instead? > In this case, the packet would consist of a STUN message riding > directly over IP > (but where the IP protocol field would specify HIP rather than STUN). > In order for the NAT to create the appropriate bindings, the STUN > message would need > to contain the source and destination HITs somewhere in the message. > The only place > to carry these in STUN is in some STUN attribute. > So this means that the NAT has to be able to do a fairly complete > parse of a STUN message. > > Requiring a HIP-aware NAT to do a fairly complete parse of a STUN > message > concerns me a bit. It seems quite unnatural to me. > > Comments? > > - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 15:32:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2BLk-0008Lv-9z; Sat, 23 Jun 2007 15:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2BLj-0008JT-HR for hipsec@ietf.org; Sat, 23 Jun 2007 15:32:47 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2BLi-0002QD-Og for hipsec@ietf.org; Sat, 23 Jun 2007 15:32:47 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 86A4E212F45; Sat, 23 Jun 2007 22:32:44 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 03EF7212DAB; Sat, 23 Jun 2007 22:32:43 +0300 (EEST) In-Reply-To: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? Date: Sat, 23 Jun 2007 22:32:42 +0300 To: Dan Wing X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: 'HIP WG' , 'Hannes Tschofenig' , 'Philip Matthews' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Firstly, I don't have any opinion on how to perform ICE, since I don't know ICE sufficiently well. Hence, I will leave that issue for others. What comes to the other issue, encoding on the wire, I'd like to express the following opinions: 1. In general, reusing encoding from Protocol X rarely works well when embedded in Protocol Y. The code-reuse argument given doesn't really hold, since it is rarely possible to simply port a part of an implementation of X into the implementation of Y. Even when that is possible, it results in a larger amount of total code. Instead, converting protocol X messages into protocol Y message format often leads to the minimal amount of total code. When re-encoded wisely, the additional amount of programming code in a cleverly implemented Y is not that larger. For example, our HIP implementation is fully modular and it is very easy to add new parameter types. 2. Security is a crucial issue here. All HIP messages are signed, and a NAT box (or a firewall) can verify the signatures, if provided with the public keys (or if it can learn them from the R1 and I2). That is a feature that I'd like to see preserved when working on NAT traversal for HIP. For these reasons, I'd be inclined to think that if one wants to use HIP-based NAT traversal for other protocols, such as NSIS, it would be best either to run the other protocol on the top of HIP, as a separate "layer", or re-encode in HIP terms, benefitting from the signatures. So, I cannot see why it would make sense to re-use STUN-over-UDP for HIP. It would increase code bloat in the HIP implementations, and it would reduce the overall security of the system, AFAICS. Finally, whether it would make sense to simply embed a STUN message into a HIP parameter (TLV), IMHO that mainly depends on whether the HIP TLV encoding/decoding engines can be easily augmented to handle STUN messages, i.e., the actual embedded content. If it can, then fine. If that doesn't make sense, e.g. because the STUN messages are ASN.1 BER encoded or TLVs in a different format or even XML, then IMHO it would be best to define new separate HIP parameters (TLVs), with the same samantics as the original STUN messages do have. [As you can see from the previous text, I haven't got a slighest idea of how STUN messages are encoded.] --Pekka Nikander On 23 Jun 2007, at 20:31, Dan Wing wrote: > The important difference with draft-tschofenig-hip-ice isn't the > encoding on-the-wire. > > Rather, the important difference is performing ICE. Those steps > are: > > Initiator: > * gather candidate addresses > * send candidate addresses to remote peer (terminator) > via a rendezvous protocol (HIP, in this case; SIP in > the traditional case of ICE) > > Terminator: > * gather its own candidate addresses > * perform connectivity checks with the remote peer > (initiator) to find a functional path to the initiator > * send candidate addresses to remote peer (initiator) via > a rendezvous protocol (HIP) > > Initiator: > * perform connectivity checks with the remote peer > (terminator) > * prioritize successful checks and determine which path > is preferred (for example: avoid UDP encapsulation, > take a path over only HIP-aware NATs if that's desirable, > avoid NATs and take direct path, etc.). This choice is > communicated to the remote peer (terminator), so it can > make the same choice so bi-directional traffic can be > assured (which is necessary to keep all the NATs open). > > > Encoding: > > The connectivity checks need to be done using the same > encapsulation and > protocol that HIP and IPsec will subsequently use for their > communication > between the two peers. There are two cases: > > * HIP-over-UDP. Here, it makes sense to use STUN-over-UDP for > those checks. > > * HIP directly over IP. Here, I concur with your email that it > may be useful to perform connectivity checks using HIP itself. > However, HIP would need encode much of the same information that > STUN encodes into HIP TLVs; thus, an opaque object that contains > a STUN message could make sense for the non-UDP HIP-over-IP case. > Failure to encode those same parameters and failure to do the > same steps as ICE will cause HIP's legacy NAT traversal to fail. > > But if we step back slightly it becomes apparent that non-HIP > protocols > would benefit from this same encoding -- NSIS comes immediately to > mind (it > needs to also work with non-NSIS-aware NATs). MIP (Mobile IP) > comes to > mind, as well (it would be useful to make sure you have > connectivity before > you switch to a new IP address, otherwise you won't be successful). > > > Two other things in your email I'm not worried about: (a) HIP- > aware NATs > having to parse the STUN messages and (b) demultiplexing STUN and HIP. > There are no HIP-aware NATs that I'm aware of, so there isn't an > installed > base of devices or software. If there is sufficient value in > multiplexing > STUN and HIP over the same UDP port, and someone wants to build a > HIP-aware > NAT, they can incur the slight difficulty in pulling a HIT out of a > STUN > message. This is perhaps 20 lines of code. Demultiplexing STUN > and HIP is > 3-4 lines of code, and has no false positives (where the > demultiplexing > fails). > > > That said, I would really like to first concentrate on the *steps* > involved > in ICE, and how to make them work with HIP. Because that must > first be > agreed upon before we can reasonably discuss HIP parameter encoding. > > -d > > >> -----Original Message----- >> From: Philip Matthews [mailto:philip_matthews@magma.ca] >> Sent: Friday, June 22, 2007 6:49 PM >> To: Miika Komu; Dan Wing; Hannes Tschofenig >> Cc: HIP WG >> Subject: ICE-for-HIP design choice: STUN or HIP? >> >> Now that there are two competing proposals for how to do ICE-for-HIP: >> http://tools.ietf.org/id/draft-ietf-hip-nat-traversal-01.txt >> and >> >> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt >> it seems to me that it would be good to step back for a moment and >> have a discussion on some basic design choices. Discussing these >> individually would help the design process, in my opinion. >> >> One of these basic questions is whether to use STUN or an enhanced >> version of HIP for binding discovery and for connectivity checks. >> Miika's document proposes to use an enhanced version of HIP, while >> Hannes's document proposes to use STUN. >> >> Here is what I see as being the pros and cons of the two approaches: >> >> STUN: >> + Protocol is already defined and deployed. >> + The usage of STUN in ICE is already defined. >> - STUN has to be run over the same port as HIP, and the only way to >> distinguish the two protocols is by header inspection. There are a >> few bits of difference, but this is not exactly a beautiful design. >> - HIP-aware NATs must be able to do a fairly complete decode of STUN >> packets. (more on this below) >> >> Enhanced HIP: >> + Fits much more naturally with the rest of HIP. >> - Requires more work to define how ICE works. >> + No weird header inspection >> + Natural behavior at HIP-aware NATs. >> - Not currently defined >> ? Not currently deployed >> >> Let me discuss two of these in more detail. >> >> The first is the question of deployment. STUN is currently deployed >> today, so there are STUN servers that a HIP node could use. But is >> this really important? If we build enhanced HIP functionality into >> HIP and into RVSes, then I think there will always be a >> public server >> around that a HIP node could use to discover its reflexive address. >> >> The rest of this message discusses the question of how to handle HIP- >> aware NATs. With a HIP-aware NAT, we could get rid of the UDP >> encapsulation, and run HIP directly over IP. This, in my opinion, is >> an important design goal. If HIP is successful, then we >> should assume >> that NATs will be upgraded to understand HIP, and this will allow us >> to get rid of the irritating UDP encapsulation. >> >> To understand how this might work, we need to agree how a HIP-aware >> NAT would operate. >> Let's consider a HIP packet sent from node X which is behind a HIP- >> aware NAT >> to a node Y which is in the public Internet, and a response coming >> back from Y to X. >> [For now, I am ignoring the fact that most of the traffic on HIP >> associations >> is actually ESP traffic and not HIP traffic. I will discuss >> this below.] >> >> Let's look at the IP addresses and HITs in the packets as they flow >> through the NAT. >> At X At N At Y >> src: (X-IP, X-HIT) (N-IP, X-HIT) >> dst: (Y-IP, Y-HIT) ------------> (Y-IP, Y-HIT)----------> >> >> src: (X-IP, X-HIT) >> (Y-IP, Y-HIT) >> dst: (Y-IP, Y-HIT) <--------- >> (N-IP, X-HIT) >> >> At the top, X sends a packet with its (private) IP address and Y's >> public IP address >> in the IP header, and its HIT and Y's HII at the HIP layer. >> At the NAT, X's private IP address is replaced by N's public address. >> When Y replies, it sends to N's public address, which gets replaced >> by the NAT >> with X's private address. >> >> Thus the NAT stores: >> mapping entry: X-HIT --> X-IP (i.e., the node >> identified by HIT >> X-HIT is at IP address X-IP) >> filtering entry: X-HIT <-- Y-HIT (i.e., the node >> identified by HIT >> X-HIT can receive packets from >> the node >> identified by Y-HIT). >> >> All this works very well if we use enchanced HIP. >> >> But how does this work if we use STUN instead? >> In this case, the packet would consist of a STUN message riding >> directly over IP >> (but where the IP protocol field would specify HIP rather than STUN). >> In order for the NAT to create the appropriate bindings, the STUN >> message would need >> to contain the source and destination HITs somewhere in the message. >> The only place >> to carry these in STUN is in some STUN attribute. >> So this means that the NAT has to be able to do a fairly complete >> parse of a STUN message. >> >> Requiring a HIP-aware NAT to do a fairly complete parse of a STUN >> message >> concerns me a bit. It seems quite unnatural to me. >> >> Comments? >> >> - Philip > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 15:52:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2BeH-0006Cm-Hv; Sat, 23 Jun 2007 15:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2BeG-0006Cd-Eg for hipsec@ietf.org; Sat, 23 Jun 2007 15:51:56 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2BeD-0006OO-Kg for hipsec@ietf.org; Sat, 23 Jun 2007 15:51:56 -0400 Received: (qmail invoked by alias); 23 Jun 2007 19:51:51 -0000 Received: from p54984F93.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.79.147] by mail.gmx.net (mp007) with SMTP; 23 Jun 2007 21:51:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18wsWId4jAwoTE+schbKBKtdCA4ZBdq1dhy4rdysD prec+9ykVFZPV8 Message-ID: <467D79D2.90000@gmx.net> Date: Sat, 23 Jun 2007 21:51:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> In-Reply-To: <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: 'HIP WG' , 'Hannes Tschofenig' , 'Philip Matthews' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Pekka, I think that main point you raised is that you would like to have a NAT that understands the HIP messages in the future and this unfortunately impacts the current protocol design of the HIP-unaware NAT traversal work. Hence, you don't really like the concept of using STUN/ICE instead. Ciao Hannes PS: The entire stuff has nothing todo with NSIS. Pekka Nikander wrote: > Firstly, I don't have any opinion on how to perform ICE, since I don't > know ICE sufficiently well. Hence, I will leave that issue for others. > > What comes to the other issue, encoding on the wire, I'd like to > express the following opinions: > > 1. In general, reusing encoding from Protocol X rarely works well when > embedded in Protocol Y. The code-reuse argument given doesn't really > hold, since it is rarely possible to simply port a part of an > implementation of X into the implementation of Y. Even when that is > possible, it results in a larger amount of total code. Instead, > converting protocol X messages into protocol Y message format often > leads to the minimal amount of total code. When re-encoded wisely, > the additional amount of programming code in a cleverly implemented Y > is not that larger. For example, our HIP implementation is fully > modular and it is very easy to add new parameter types. > > 2. Security is a crucial issue here. All HIP messages are signed, and > a NAT box (or a firewall) can verify the signatures, if provided with > the public keys (or if it can learn them from the R1 and I2). That is > a feature that I'd like to see preserved when working on NAT traversal > for HIP. > > For these reasons, I'd be inclined to think that if one wants to use > HIP-based NAT traversal for other protocols, such as NSIS, it would be > best either to run the other protocol on the top of HIP, as a separate > "layer", or re-encode in HIP terms, benefitting from the signatures. > > So, I cannot see why it would make sense to re-use STUN-over-UDP for > HIP. It would increase code bloat in the HIP implementations, and it > would reduce the overall security of the system, AFAICS. > > Finally, whether it would make sense to simply embed a STUN message > into a HIP parameter (TLV), IMHO that mainly depends on whether the > HIP TLV encoding/decoding engines can be easily augmented to handle > STUN messages, i.e., the actual embedded content. If it can, then > fine. If that doesn't make sense, e.g. because the STUN messages are > ASN.1 BER encoded or TLVs in a different format or even XML, then IMHO > it would be best to define new separate HIP parameters (TLVs), with > the same samantics as the original STUN messages do have. [As you can > see from the previous text, I haven't got a slighest idea of how STUN > messages are encoded.] > > --Pekka Nikander > > > > On 23 Jun 2007, at 20:31, Dan Wing wrote: > >> The important difference with draft-tschofenig-hip-ice isn't the >> encoding on-the-wire. >> >> Rather, the important difference is performing ICE. Those steps >> are: >> >> Initiator: >> * gather candidate addresses >> * send candidate addresses to remote peer (terminator) >> via a rendezvous protocol (HIP, in this case; SIP in >> the traditional case of ICE) >> >> Terminator: >> * gather its own candidate addresses >> * perform connectivity checks with the remote peer >> (initiator) to find a functional path to the initiator >> * send candidate addresses to remote peer (initiator) via >> a rendezvous protocol (HIP) >> >> Initiator: >> * perform connectivity checks with the remote peer >> (terminator) >> * prioritize successful checks and determine which path >> is preferred (for example: avoid UDP encapsulation, >> take a path over only HIP-aware NATs if that's desirable, >> avoid NATs and take direct path, etc.). This choice is >> communicated to the remote peer (terminator), so it can >> make the same choice so bi-directional traffic can be >> assured (which is necessary to keep all the NATs open). >> >> >> Encoding: >> >> The connectivity checks need to be done using the same encapsulation and >> protocol that HIP and IPsec will subsequently use for their >> communication >> between the two peers. There are two cases: >> >> * HIP-over-UDP. Here, it makes sense to use STUN-over-UDP for >> those checks. >> >> * HIP directly over IP. Here, I concur with your email that it >> may be useful to perform connectivity checks using HIP itself. >> However, HIP would need encode much of the same information that >> STUN encodes into HIP TLVs; thus, an opaque object that contains >> a STUN message could make sense for the non-UDP HIP-over-IP case. >> Failure to encode those same parameters and failure to do the >> same steps as ICE will cause HIP's legacy NAT traversal to fail. >> >> But if we step back slightly it becomes apparent that non-HIP protocols >> would benefit from this same encoding -- NSIS comes immediately to >> mind (it >> needs to also work with non-NSIS-aware NATs). MIP (Mobile IP) comes to >> mind, as well (it would be useful to make sure you have connectivity >> before >> you switch to a new IP address, otherwise you won't be successful). >> >> >> Two other things in your email I'm not worried about: (a) HIP-aware >> NATs >> having to parse the STUN messages and (b) demultiplexing STUN and HIP. >> There are no HIP-aware NATs that I'm aware of, so there isn't an >> installed >> base of devices or software. If there is sufficient value in >> multiplexing >> STUN and HIP over the same UDP port, and someone wants to build a >> HIP-aware >> NAT, they can incur the slight difficulty in pulling a HIT out of a STUN >> message. This is perhaps 20 lines of code. Demultiplexing STUN and >> HIP is >> 3-4 lines of code, and has no false positives (where the demultiplexing >> fails). >> >> >> That said, I would really like to first concentrate on the *steps* >> involved >> in ICE, and how to make them work with HIP. Because that must first be >> agreed upon before we can reasonably discuss HIP parameter encoding. >> >> -d >> >> >>> -----Original Message----- >>> From: Philip Matthews [mailto:philip_matthews@magma.ca] >>> Sent: Friday, June 22, 2007 6:49 PM >>> To: Miika Komu; Dan Wing; Hannes Tschofenig >>> Cc: HIP WG >>> Subject: ICE-for-HIP design choice: STUN or HIP? >>> >>> Now that there are two competing proposals for how to do ICE-for-HIP: >>> http://tools.ietf.org/id/draft-ietf-hip-nat-traversal-01.txt >>> and >>> >>> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt >>> it seems to me that it would be good to step back for a moment and >>> have a discussion on some basic design choices. Discussing these >>> individually would help the design process, in my opinion. >>> >>> One of these basic questions is whether to use STUN or an enhanced >>> version of HIP for binding discovery and for connectivity checks. >>> Miika's document proposes to use an enhanced version of HIP, while >>> Hannes's document proposes to use STUN. >>> >>> Here is what I see as being the pros and cons of the two approaches: >>> >>> STUN: >>> + Protocol is already defined and deployed. >>> + The usage of STUN in ICE is already defined. >>> - STUN has to be run over the same port as HIP, and the only way to >>> distinguish the two protocols is by header inspection. There are a >>> few bits of difference, but this is not exactly a beautiful design. >>> - HIP-aware NATs must be able to do a fairly complete decode of STUN >>> packets. (more on this below) >>> >>> Enhanced HIP: >>> + Fits much more naturally with the rest of HIP. >>> - Requires more work to define how ICE works. >>> + No weird header inspection >>> + Natural behavior at HIP-aware NATs. >>> - Not currently defined >>> ? Not currently deployed >>> >>> Let me discuss two of these in more detail. >>> >>> The first is the question of deployment. STUN is currently deployed >>> today, so there are STUN servers that a HIP node could use. But is >>> this really important? If we build enhanced HIP functionality into >>> HIP and into RVSes, then I think there will always be a >>> public server >>> around that a HIP node could use to discover its reflexive address. >>> >>> The rest of this message discusses the question of how to handle HIP- >>> aware NATs. With a HIP-aware NAT, we could get rid of the UDP >>> encapsulation, and run HIP directly over IP. This, in my opinion, is >>> an important design goal. If HIP is successful, then we >>> should assume >>> that NATs will be upgraded to understand HIP, and this will allow us >>> to get rid of the irritating UDP encapsulation. >>> >>> To understand how this might work, we need to agree how a HIP-aware >>> NAT would operate. >>> Let's consider a HIP packet sent from node X which is behind a HIP- >>> aware NAT >>> to a node Y which is in the public Internet, and a response coming >>> back from Y to X. >>> [For now, I am ignoring the fact that most of the traffic on HIP >>> associations >>> is actually ESP traffic and not HIP traffic. I will discuss >>> this below.] >>> >>> Let's look at the IP addresses and HITs in the packets as they flow >>> through the NAT. >>> At X At N At Y >>> src: (X-IP, X-HIT) (N-IP, X-HIT) >>> dst: (Y-IP, Y-HIT) ------------> (Y-IP, Y-HIT)----------> >>> >>> src: (X-IP, X-HIT) >>> (Y-IP, Y-HIT) >>> dst: (Y-IP, Y-HIT) <--------- >>> (N-IP, X-HIT) >>> >>> At the top, X sends a packet with its (private) IP address and Y's >>> public IP address >>> in the IP header, and its HIT and Y's HII at the HIP layer. >>> At the NAT, X's private IP address is replaced by N's public address. >>> When Y replies, it sends to N's public address, which gets replaced >>> by the NAT >>> with X's private address. >>> >>> Thus the NAT stores: >>> mapping entry: X-HIT --> X-IP (i.e., the node >>> identified by HIT >>> X-HIT is at IP address X-IP) >>> filtering entry: X-HIT <-- Y-HIT (i.e., the node >>> identified by HIT >>> X-HIT can receive packets from >>> the node >>> identified by Y-HIT). >>> >>> All this works very well if we use enchanced HIP. >>> >>> But how does this work if we use STUN instead? >>> In this case, the packet would consist of a STUN message riding >>> directly over IP >>> (but where the IP protocol field would specify HIP rather than STUN). >>> In order for the NAT to create the appropriate bindings, the STUN >>> message would need >>> to contain the source and destination HITs somewhere in the message. >>> The only place >>> to carry these in STUN is in some STUN attribute. >>> So this means that the NAT has to be able to do a fairly complete >>> parse of a STUN message. >>> >>> Requiring a HIP-aware NAT to do a fairly complete parse of a STUN >>> message >>> concerns me a bit. It seems quite unnatural to me. >>> >>> Comments? >>> >>> - Philip >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 16:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Bpn-0006QL-Jr; Sat, 23 Jun 2007 16:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Bpm-0006Pv-PA for hipsec@ietf.org; Sat, 23 Jun 2007 16:03:50 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2Bpl-0002AI-VJ for hipsec@ietf.org; Sat, 23 Jun 2007 16:03:50 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C246F212F45; Sat, 23 Jun 2007 23:03:48 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3D551212DAB; Sat, 23 Jun 2007 23:03:48 +0300 (EEST) In-Reply-To: <467D79D2.90000@gmx.net> References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> <467D79D2.90000@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? Date: Sat, 23 Jun 2007 23:03:46 +0300 To: HIP WG X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: Hannes Tschofenig , Hannes Tschofenig , Philip Matthews X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Dear WG, From my point of view, Mr. Tschofenig is trying to read my words in a way that I wasn't intending. I'm taking that off-line, and will try to come back here once this misunderstanding has been cleared. I tried to say that IMHO using HIP packet formats makes sense from both security and implementation point of view, even for the HIP- tunneled-over-UDP case. Nothing more and nothing less. My reference to NSIS was only due to Mr. Wing's reference to that. --Pekka Nikander On 23 Jun 2007, at 22:51, Hannes Tschofenig wrote: > Hi Pekka, > > I think that main point you raised is that you would like to have a > NAT that understands the HIP messages in the future and this > unfortunately impacts the current protocol design of the HIP- > unaware NAT traversal work. Hence, you don't really like the > concept of using STUN/ICE instead. > > Ciao > Hannes > > PS: The entire stuff has nothing todo with NSIS. > > > Pekka Nikander wrote: >> Firstly, I don't have any opinion on how to perform ICE, since I >> don't know ICE sufficiently well. Hence, I will leave that issue >> for others. >> >> What comes to the other issue, encoding on the wire, I'd like to >> express the following opinions: >> >> 1. In general, reusing encoding from Protocol X rarely works well >> when embedded in Protocol Y. The code-reuse argument given >> doesn't really hold, since it is rarely possible to simply port a >> part of an implementation of X into the implementation of Y. Even >> when that is possible, it results in a larger amount of total >> code. Instead, converting protocol X messages into protocol Y >> message format often leads to the minimal amount of total code. >> When re-encoded wisely, the additional amount of programming code >> in a cleverly implemented Y is not that larger. For example, our >> HIP implementation is fully modular and it is very easy to add new >> parameter types. >> >> 2. Security is a crucial issue here. All HIP messages are signed, >> and a NAT box (or a firewall) can verify the signatures, if >> provided with the public keys (or if it can learn them from the R1 >> and I2). That is a feature that I'd like to see preserved when >> working on NAT traversal for HIP. >> >> For these reasons, I'd be inclined to think that if one wants to >> use HIP-based NAT traversal for other protocols, such as NSIS, it >> would be best either to run the other protocol on the top of HIP, >> as a separate "layer", or re-encode in HIP terms, benefitting from >> the signatures. >> >> So, I cannot see why it would make sense to re-use STUN-over-UDP >> for HIP. It would increase code bloat in the HIP implementations, >> and it would reduce the overall security of the system, AFAICS. >> >> Finally, whether it would make sense to simply embed a STUN >> message into a HIP parameter (TLV), IMHO that mainly depends on >> whether the HIP TLV encoding/decoding engines can be easily >> augmented to handle STUN messages, i.e., the actual embedded >> content. If it can, then fine. If that doesn't make sense, e.g. >> because the STUN messages are ASN.1 BER encoded or TLVs in a >> different format or even XML, then IMHO it would be best to define >> new separate HIP parameters (TLVs), with the same samantics as the >> original STUN messages do have. [As you can see from the previous >> text, I haven't got a slighest idea of how STUN messages are >> encoded.] >> >> --Pekka Nikander >> >> >> >> On 23 Jun 2007, at 20:31, Dan Wing wrote: >> >>> The important difference with draft-tschofenig-hip-ice isn't the >>> encoding on-the-wire. >>> >>> Rather, the important difference is performing ICE. Those steps >>> are: >>> >>> Initiator: >>> * gather candidate addresses >>> * send candidate addresses to remote peer (terminator) >>> via a rendezvous protocol (HIP, in this case; SIP in >>> the traditional case of ICE) >>> >>> Terminator: >>> * gather its own candidate addresses >>> * perform connectivity checks with the remote peer >>> (initiator) to find a functional path to the initiator >>> * send candidate addresses to remote peer (initiator) via >>> a rendezvous protocol (HIP) >>> >>> Initiator: >>> * perform connectivity checks with the remote peer >>> (terminator) >>> * prioritize successful checks and determine which path >>> is preferred (for example: avoid UDP encapsulation, >>> take a path over only HIP-aware NATs if that's desirable, >>> avoid NATs and take direct path, etc.). This choice is >>> communicated to the remote peer (terminator), so it can >>> make the same choice so bi-directional traffic can be >>> assured (which is necessary to keep all the NATs open). >>> >>> >>> Encoding: >>> >>> The connectivity checks need to be done using the same >>> encapsulation and >>> protocol that HIP and IPsec will subsequently use for their >>> communication >>> between the two peers. There are two cases: >>> >>> * HIP-over-UDP. Here, it makes sense to use STUN-over-UDP for >>> those checks. >>> >>> * HIP directly over IP. Here, I concur with your email that it >>> may be useful to perform connectivity checks using HIP itself. >>> However, HIP would need encode much of the same information that >>> STUN encodes into HIP TLVs; thus, an opaque object that contains >>> a STUN message could make sense for the non-UDP HIP-over-IP >>> case. >>> Failure to encode those same parameters and failure to do the >>> same steps as ICE will cause HIP's legacy NAT traversal to fail. >>> >>> But if we step back slightly it becomes apparent that non-HIP >>> protocols >>> would benefit from this same encoding -- NSIS comes immediately >>> to mind (it >>> needs to also work with non-NSIS-aware NATs). MIP (Mobile IP) >>> comes to >>> mind, as well (it would be useful to make sure you have >>> connectivity before >>> you switch to a new IP address, otherwise you won't be successful). >>> >>> >>> Two other things in your email I'm not worried about: (a) HIP- >>> aware NATs >>> having to parse the STUN messages and (b) demultiplexing STUN and >>> HIP. >>> There are no HIP-aware NATs that I'm aware of, so there isn't an >>> installed >>> base of devices or software. If there is sufficient value in >>> multiplexing >>> STUN and HIP over the same UDP port, and someone wants to build a >>> HIP-aware >>> NAT, they can incur the slight difficulty in pulling a HIT out of >>> a STUN >>> message. This is perhaps 20 lines of code. Demultiplexing STUN >>> and HIP is >>> 3-4 lines of code, and has no false positives (where the >>> demultiplexing >>> fails). >>> >>> >>> That said, I would really like to first concentrate on the >>> *steps* involved >>> in ICE, and how to make them work with HIP. Because that must >>> first be >>> agreed upon before we can reasonably discuss HIP parameter encoding. >>> >>> -d >>> >>> >>>> -----Original Message----- >>>> From: Philip Matthews [mailto:philip_matthews@magma.ca] >>>> Sent: Friday, June 22, 2007 6:49 PM >>>> To: Miika Komu; Dan Wing; Hannes Tschofenig >>>> Cc: HIP WG >>>> Subject: ICE-for-HIP design choice: STUN or HIP? >>>> >>>> Now that there are two competing proposals for how to do ICE-for- >>>> HIP: >>>> http://tools.ietf.org/id/draft-ietf-hip-nat-traversal-01.txt >>>> and >>>> http://www.ietf.org/internet-drafts/draft-tschofenig-hip- >>>> ice-00.txt >>>> it seems to me that it would be good to step back for a moment and >>>> have a discussion on some basic design choices. Discussing these >>>> individually would help the design process, in my opinion. >>>> >>>> One of these basic questions is whether to use STUN or an enhanced >>>> version of HIP for binding discovery and for connectivity checks. >>>> Miika's document proposes to use an enhanced version of HIP, while >>>> Hannes's document proposes to use STUN. >>>> >>>> Here is what I see as being the pros and cons of the two >>>> approaches: >>>> >>>> STUN: >>>> + Protocol is already defined and deployed. >>>> + The usage of STUN in ICE is already defined. >>>> - STUN has to be run over the same port as HIP, and the only way to >>>> distinguish the two protocols is by header inspection. There are a >>>> few bits of difference, but this is not exactly a beautiful design. >>>> - HIP-aware NATs must be able to do a fairly complete decode of >>>> STUN >>>> packets. (more on this below) >>>> >>>> Enhanced HIP: >>>> + Fits much more naturally with the rest of HIP. >>>> - Requires more work to define how ICE works. >>>> + No weird header inspection >>>> + Natural behavior at HIP-aware NATs. >>>> - Not currently defined >>>> ? Not currently deployed >>>> >>>> Let me discuss two of these in more detail. >>>> >>>> The first is the question of deployment. STUN is currently deployed >>>> today, so there are STUN servers that a HIP node could use. But is >>>> this really important? If we build enhanced HIP functionality into >>>> HIP and into RVSes, then I think there will always be a >>>> public server >>>> around that a HIP node could use to discover its reflexive address. >>>> >>>> The rest of this message discusses the question of how to handle >>>> HIP- >>>> aware NATs. With a HIP-aware NAT, we could get rid of the UDP >>>> encapsulation, and run HIP directly over IP. This, in my >>>> opinion, is >>>> an important design goal. If HIP is successful, then we >>>> should assume >>>> that NATs will be upgraded to understand HIP, and this will >>>> allow us >>>> to get rid of the irritating UDP encapsulation. >>>> >>>> To understand how this might work, we need to agree how a HIP-aware >>>> NAT would operate. >>>> Let's consider a HIP packet sent from node X which is behind a HIP- >>>> aware NAT >>>> to a node Y which is in the public Internet, and a response coming >>>> back from Y to X. >>>> [For now, I am ignoring the fact that most of the traffic on HIP >>>> associations >>>> is actually ESP traffic and not HIP traffic. I will discuss >>>> this below.] >>>> >>>> Let's look at the IP addresses and HITs in the packets as they flow >>>> through the NAT. >>>> At X At N At Y >>>> src: (X-IP, X-HIT) (N-IP, X-HIT) >>>> dst: (Y-IP, Y-HIT) ------------> (Y-IP, Y-HIT)----------> >>>> >>>> src: (X-IP, X-HIT) >>>> (Y-IP, Y-HIT) >>>> dst: (Y-IP, Y-HIT) <--------- >>>> (N-IP, X-HIT) >>>> >>>> At the top, X sends a packet with its (private) IP address and Y's >>>> public IP address >>>> in the IP header, and its HIT and Y's HII at the HIP layer. >>>> At the NAT, X's private IP address is replaced by N's public >>>> address. >>>> When Y replies, it sends to N's public address, which gets replaced >>>> by the NAT >>>> with X's private address. >>>> >>>> Thus the NAT stores: >>>> mapping entry: X-HIT --> X-IP (i.e., the node >>>> identified by HIT >>>> X-HIT is at IP address X-IP) >>>> filtering entry: X-HIT <-- Y-HIT (i.e., the node >>>> identified by HIT >>>> X-HIT can receive packets from >>>> the node >>>> identified by Y-HIT). >>>> >>>> All this works very well if we use enchanced HIP. >>>> >>>> But how does this work if we use STUN instead? >>>> In this case, the packet would consist of a STUN message riding >>>> directly over IP >>>> (but where the IP protocol field would specify HIP rather than >>>> STUN). >>>> In order for the NAT to create the appropriate bindings, the STUN >>>> message would need >>>> to contain the source and destination HITs somewhere in the >>>> message. >>>> The only place >>>> to carry these in STUN is in some STUN attribute. >>>> So this means that the NAT has to be able to do a fairly complete >>>> parse of a STUN message. >>>> >>>> Requiring a HIP-aware NAT to do a fairly complete parse of a STUN >>>> message >>>> concerns me a bit. It seems quite unnatural to me. >>>> >>>> Comments? >>>> >>>> - Philip >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >>> >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 20:32:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2G1d-0002ij-PU; Sat, 23 Jun 2007 20:32:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2G1c-0002iQ-Pw for hipsec@lists.ietf.org; Sat, 23 Jun 2007 20:32:20 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2G1b-0005H5-Ge for hipsec@lists.ietf.org; Sat, 23 Jun 2007 20:32:20 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I2G1X-00041q-3C; Sat, 23 Jun 2007 20:32:16 -0400 In-Reply-To: <467D4042.2050805@gmx.net> References: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> <7E115CCB-798C-474E-B78E-223D06311AF0@magma.ca> <467D4042.2050805@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <284CAE3D-9E8F-419E-8400-C6B1C258B8E6@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] draft-tschofenig-hip-ice-00.txt Date: Sat, 23 Jun 2007 20:32:19 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: hipsec@lists.ietf.org, Hannes Tschofenig X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 23-Jun-07, at 11:46 , Hannes Tschofenig wrote: > Hi Phillip, > > Philip Matthews wrote: >> A few questions/comments on this draft: >> >> 1) Can you explain in more detail how you see the ICE attributes >> being encoded? >> > Currently, we went for a really simple approach: We just take the > same format as in ICE and dump them into an attribute for exchange > in HIP. Maximum code reuse was the goal. One can obviously change > the encoding of the attribute. Let me make sure I understand what you mean. Here is the example SDP from section 4.3 of draft-ietf-mmusic-ice-16.txt v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 It sounds like your proposed HIP parameter would contain all the characters between the quote marks below: "c=IN IP4 192.0.2.3 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998" Here I have removed the "v=", "o=", "s=", "t=", and "b=" lines. Do you also remove the "m=" and "c=" lines? (these play an important role in ICE). Is this correct? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 20:39:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2G8Y-0006dP-D2; Sat, 23 Jun 2007 20:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2G8W-0006dK-Jm for hipsec@lists.ietf.org; Sat, 23 Jun 2007 20:39:28 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2G8V-0006ej-Dd for hipsec@lists.ietf.org; Sat, 23 Jun 2007 20:39:28 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I2G8c-0001pD-EH; Sat, 23 Jun 2007 20:39:34 -0400 In-Reply-To: <04b201c7b5b3$2f1ea760$78a36b80@amer.cisco.com> References: <04b201c7b5b3$2f1ea760$78a36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] draft-tschofenig-hip-ice-00.txt Date: Sat, 23 Jun 2007 20:39:30 -0400 To: "Dan Wing" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: hipsec@lists.ietf.org, 'Hannes Tschofenig' , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 23-Jun-07, at 12:25 , Dan Wing wrote: >>> 3) It seems weird to me to use the ufrag stuff of ICE (= a random >>> endpoint identifier) >>> when HIP already has HITs. >> >> Good observation. I have to think about it if it makes sense >> to change that. > > stick the HIT into the USERNAME, then. > > -d That could be a good choice. Each end puts its HIT in the ufrag (expressed in hex, say), and then the STUN username would be : - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 21:41:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2H65-0002JP-RI; Sat, 23 Jun 2007 21:41:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2H63-0002Hu-7B for hipsec@ietf.org; Sat, 23 Jun 2007 21:40:59 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2H62-0001T4-TT for hipsec@ietf.org; Sat, 23 Jun 2007 21:40:59 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I2H5y-0001zz-1x; Sat, 23 Jun 2007 21:40:54 -0400 In-Reply-To: <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <999BE24F-525B-48A7-BA3A-C2A115D74DAD@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sat, 23 Jun 2007 21:40:57 -0400 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] Brief introduction to STUN X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 23-Jun-07, at 15:32 , Pekka Nikander wrote: > As you can see from the previous text, I haven't got a slighest > idea of how STUN messages are encoded.] > STUN is defined in RFC 3489 with a significant update in draft-ietf- behave-3489bis. It is a binary protocol consisting of a fixed header followed by zero or more TLVs (called Attributes in STUN). The header from draft-ietf-behave-3489bis looks as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ |0 0| STUN Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ Transaction ID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ and each attribute has the usual TLV structure 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Value .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ There are a number of different Attribute types defined, and a typical STUN message usually contains a number of Attributes. STUN messages are sent as part of "transactions". A transaction is either a request/response transaction where a "client" sends a request and "sever" replies with a response (=success) or an error response (=error); or an indication, where a "client" sends an indication to a server, but does not get back a response. ICE uses STUN in two different ways: 1) To determine the public address and port that a NAT has allocated that corresponds to the private address and port of an endpoint. To do this, an endpoint sends a STUN BindingRequest message to a server on the public Internet, which replies with a BindingResponse message. The server places the source address and port it saw in the received UDP message into an attribute in the BindingResponse message. In this way, the endpoint learns the public address and port that the NAT has assigned it. 2) To determine if two endpoints can communicate using a given 5-type of (source IP address, source port, dest IP address, dest port, protocol). To do this, both endpoints send STUN BindingRequest messages to each other using the 5-tuple. If an end gets a response, it knows that the 5-tuple works. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 23 22:05:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2HTY-0005Pz-M5; Sat, 23 Jun 2007 22:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2HTW-0005Pn-RK for hipsec@ietf.org; Sat, 23 Jun 2007 22:05:14 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2HTV-00075X-Hy for hipsec@ietf.org; Sat, 23 Jun 2007 22:05:14 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I2HTP-0008SW-0o; Sat, 23 Jun 2007 22:05:07 -0400 In-Reply-To: <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sat, 23 Jun 2007 22:05:10 -0400 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'HIP WG' , 'Hannes Tschofenig' Subject: [Hipsec] Brief introduction to ICE X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org ICE is officially a extension of SDP (Session Description Protocol). ICE is defined in draft-ietf-mmusic-ice, and the current SDP definition is in RFC 4566. SDP is a text-based protocol for describing multimedia sessions. An SDP message consists of a number of lines, where each line starts with a single letter and is followed by an equals sign. For example: v=0 o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 s= c=IN IP4 192.0.2.3 t=0 0 a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-ufrag:8hhY m=audio 45664 RTP/AVP 0 b=RS:0 b=RR:0 a=rtpmap:0 PCMU/8000 a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 10.0.1.1 rport 8998 The two endpoints that want to communicate do an Offer-Answer exchange. That is, one endpoint sends the other an SDP message (dubbed the Offer), and the other end replies with a second SDP message (dubbed the Answer). This is basically a standard capability exchange seen in many other protocols. Neither SDP nor ICE define how the Offer and Answer are sent to the other end. This is typically done using some out-of-band signaling mechanism. One common example is SIP signaling through intermediate proxies. For HIP, a Base Exchange through an RVS could do the trick, where the Offer and Answer are carried in HIP messages. With ICE, the Offer and Answer include one or more "candidates". Each candidate is an (IP address, port, protocol) combination along with some related information. For example, the line a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host specifies a UDP candidate with address 10.0.1.1 and port 8998, along with some other information. Using the Offer/Answer exchange, the two endpoints exchange sets of candidates. Each endpoint typically includes all the candidates that it knows about that can be used to reach it. These are both its private (address,port) combinations, as well as public (address,port) combinations which it learns by doing STUN BindingRequest/BindingResponse exchanges with a server. Each endpoint then forms all possible pairs of (local candidate, remote candidate), sorts these pairs in a defined way, and then performs connectivity checks to see if this pair can be used to communicate between the two endpoints. The connectivity checks are also performed using STUN messages. A longer, but still tutorial, introduction to ICE can be found in the Nov 2006 issue of the IETF Journal: http://www.isoc.org/tools/blogs/ietfjournal/?p=117#more-117 - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 02:11:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2LJy-0008E8-Dh; Sun, 24 Jun 2007 02:11:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2LJx-0008E0-2v for hipsec@ietf.org; Sun, 24 Jun 2007 02:11:37 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2LJv-0003nN-Ig for hipsec@ietf.org; Sun, 24 Jun 2007 02:11:37 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1A373212F6F; Sun, 24 Jun 2007 09:11:34 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id ABD11212F45; Sun, 24 Jun 2007 09:11:33 +0300 (EEST) In-Reply-To: References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4234FDD1-CC6C-4F04-9A29-1556F75962C6@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Sun, 24 Jun 2007 09:11:32 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: 'HIP WG' , 'Hannes Tschofenig' Subject: [Hipsec] Re: Brief introduction to ICE X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 24 Jun 2007, at 05:05, Philip Matthews wrote: > With ICE, the Offer and Answer include one or more "candidates". > Each candidate is an (IP address, port, protocol) combination along > with some related information. > For example, the line > a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > specifies a UDP candidate with address 10.0.1.1 and port 8998, > along with some other information. That kind of semantics is exactly why we made the HIP LOCATOR parameter extensible. That is, the rationale back then was to be able to encode not only IP addresses but more complex and variable underlying addresses in a LOCATOR. For details, see Section 4 of http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-05.txt Briefly, the LOCATOR carries one or more LOCATORS (candidates in ICE), each with the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Traffic Type | Locator Type | Locator Length | Reserved |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Locator Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ | Locator | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+ Currently only the following locator types are defined: 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [8] (128 bits long). This locator type is defined primarily for non-ESP- based usage. 1: The concatenation of an ESP SPI (first 32 bits) followed by an IPv6 address or an IPv4-in-IPv6 format IPv4 address (an additional 128 bits). This IP address is defined primarily for ESP-based usage. However, it would be trivial to define a new format for UDP encapsulation; indeed, we had discussions about including it, but I don't remember the details of that discussion any more. IIRC, back then we decided to delay the definition of that format until the NAT traversal discussions mature enough. > Using the Offer/Answer exchange, the two endpoints exchange sets of > candidates. The HIP MM exchange allows the endpoints to exchange LOCATOR sets. > Each endpoint typically includes all the candidates that it knows > about that can be used > to reach it. These are both its private (address,port) > combinations, as well as public > (address,port) combinations which it learns by doing STUN > BindingRequest/BindingResponse > exchanges with a server. To me, this sounds like the exchange could trivially map to the HIP mm exchange, but of course I may be completely wrong. > Each endpoint then forms all possible pairs of (local candidate, > remote candidate), > sorts these pairs in a defined way, and then performs connectivity > checks to see > if this pair can be used to communicate between the two endpoints. > The connectivity > checks are also performed using STUN messages. That sounds quite similar to the SHIM6 connectivity checks, to me. See http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- detection-08.txt (As an information point, one should notice that the SHIM6 and HIP protocols were explicitly designed to use the same packet formats, to ease sharing mechanisms between the two.) --Pekka Nikander _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 02:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2LYo-0006yI-7a; Sun, 24 Jun 2007 02:26:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2LYn-0006yA-Fv for hipsec@ietf.org; Sun, 24 Jun 2007 02:26:57 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2LYm-0000bf-VN for hipsec@ietf.org; Sun, 24 Jun 2007 02:26:57 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 010B8212F6F; Sun, 24 Jun 2007 09:26:56 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5A571212F45; Sun, 24 Jun 2007 09:26:55 +0300 (EEST) In-Reply-To: <999BE24F-525B-48A7-BA3A-C2A115D74DAD@magma.ca> References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> <999BE24F-525B-48A7-BA3A-C2A115D74DAD@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <176780D8-F5C6-4235-8AAB-D14F5C19BE52@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Sun, 24 Jun 2007 09:26:54 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] Re: Brief introduction to STUN X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > and each attribute has the usual TLV structure > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Type | > Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | > Value .... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ The good news is that this is almost the same as the HIP parameter format: 5.2.1. TLV Format .... All of the TLV parameters have a length (including Type and Length fields) which is a multiple of 8 bytes. When needed, padding MUST be added to the end of the parameter so that the total length becomes a multiple of 8 bytes. This rule ensures proper alignment of data. Any added padding bytes MUST be zeroed by the sender, and their values SHOULD NOT be checked by the receiver. Consequently, the Length field indicates the length of the Contents field (in bytes). The total length of the TLV parameter (including Type, Length, Contents, and Padding) is related to the Length field according to the following formula: Total Length = 11 + Length - (Length + 3) % 8; 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |C| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Contents / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Therefore, mapping STUN Attributes to HIP Parameters should be a trivial task: 1. Define a mapping of Type values, if needed. Of course, if an equality-based mapping would work, that would be excellent, but I doubt. 2. Use the HIP Length computation method in order to make the handling of all HIP parameters, including those based on STUN, to use the same method. 3. Use the STUN definition for Value as the HIP Contents. Though, for some Attributes it might be better to use already defined HIP equivalents. For example, I could imagine that it would make sense to use HIP Sequence Number and Acknowledgement parameters. And as already discussed in my previous message, for ICE candidates it would probably be better to use the HIP LOCATOR parameter, extended in a suitable way to encode the required locator formats in a sensible way. One benefit here might be that HIP contains mechanisms that can be used to allow "transactions" to overlap. > ICE uses STUN in two different ways: > > 1) To determine the public address and port that a NAT has allocated > that corresponds to the private address and port of an endpoint. > To do this, an endpoint sends a STUN BindingRequest message to a > server > on the public Internet, which replies with a BindingResponse message. This could be mapped on the top of the HIP (RVS) Registration protocol. The BindingRequest (or equivalent info mapped on the Registration protocol) could be carried in a REG_REQ Parameter, or next to it. Hence, I see here two choices: 1. Simply carry BindingRequest as an additional parameter wherever you carry a REG_REQ parameter, or 2. Map the BindingRequest into an equivalent HIP REG_REQ parameter. > The server places the source address and port it saw in the received > UDP message into an attribute in the BindingResponse message. > In this way, the endpoint learns the public address and port that the > NAT has assigned it. Here there might be three different design choices: 1. Simply carry BindingResponse in any message responding to a previous message carring a BindingRequest. 2. Define a REQ_RES extension that carries the information in BindingResponse. 3. Define a variant of LOCATOR that carries the information in BindingResponse. Of course, there might be other sensible alternatives in both cases. > 2) To determine if two endpoints can communicate using a given 5-type > of (source IP address, source port, dest IP address, dest port, > protocol). > To do this, both endpoints send STUN BindingRequest messages to > each other > using the 5-tuple. If an end gets a response, it knows that the 5- > tuple > works. As an initial approximiation, I think that a variant of the HIP MM protocol, drawing from the ICE experience and SHIM6 exploration formats, might be the best way forward. But here I might be completely wrong; there seems to be subtleties that I don't understand. My main point here is that NAT such exploration should not be limited to the NAT traversal case but should allow any two HIP hosts to explore the characteristics of all paths, independent of whether the paths are based on IPv4, IPv6, and contain no, transparent, or explicit middle boxes. From my point of view, most of the required components for such a mechanism are already there scattered over the various HIP drafts; what is missing is the algorithms and state machine definitions for utilising them. But perhaps I'm too simple minded here. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 04:34:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2NYO-0004ao-3G; Sun, 24 Jun 2007 04:34:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2NYM-0004aj-Fs for hipsec@lists.ietf.org; Sun, 24 Jun 2007 04:34:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2NYL-0003K3-2z for hipsec@lists.ietf.org; Sun, 24 Jun 2007 04:34:38 -0400 Received: (qmail invoked by alias); 24 Jun 2007 08:34:35 -0000 Received: from p54985987.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.89.135] by mail.gmx.net (mp032) with SMTP; 24 Jun 2007 10:34:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+qHiIDdoWqbnOql0gJncuclxFOBQ6SqDEcnfO5Tp C2/SXYH3s3gcyO Message-ID: <467E2C9B.4060800@gmx.net> Date: Sun, 24 Jun 2007 10:34:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [Hipsec] draft-tschofenig-hip-ice-00.txt References: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> <7E115CCB-798C-474E-B78E-223D06311AF0@magma.ca> <467D4042.2050805@gmx.net> <284CAE3D-9E8F-419E-8400-C6B1C258B8E6@magma.ca> In-Reply-To: <284CAE3D-9E8F-419E-8400-C6B1C258B8E6@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: hipsec@lists.ietf.org, Hannes Tschofenig X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Phillip, Philip Matthews wrote: > > On 23-Jun-07, at 11:46 , Hannes Tschofenig wrote: > >> Hi Phillip, >> >> Philip Matthews wrote: >>> A few questions/comments on this draft: >>> >>> 1) Can you explain in more detail how you see the ICE attributes >>> being encoded? >>> >> Currently, we went for a really simple approach: We just take the >> same format as in ICE and dump them into an attribute for exchange in >> HIP. Maximum code reuse was the goal. One can obviously change the >> encoding of the attribute. > > Let me make sure I understand what you mean. > Here is the example SDP from section 4.3 of draft-ietf-mmusic-ice-16.txt > > v=0 > o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 > s= > c=IN IP4 192.0.2.3 > t=0 0 > a=ice-pwd:asd88fgpdd777uzjYhagZg > a=ice-ufrag:8hhY > m=audio 45664 RTP/AVP 0 > b=RS:0 > b=RR:0 > a=rtpmap:0 PCMU/8000 > a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr > 10.0.1.1 rport 8998 > > It sounds like your proposed HIP parameter would contain all the > characters between the quote marks below: > "c=IN IP4 192.0.2.3 > a=ice-pwd:asd88fgpdd777uzjYhagZg > a=ice-ufrag:8hhY > m=audio 45664 RTP/AVP 0 > a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host > a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr > 10.0.1.1 rport 8998" > Here I have removed the "v=", "o=", "s=", "t=", and "b=" lines. Do > you also remove the "m=" and "c=" lines? > (these play an important role in ICE). > ICE needs these attributes: "candidate", "remote-candidates", "ice-lite", "ice-mismatch", "ice- ufrag", "ice-pwd" "ice-options" Hence, "c=IN IP4 192.0.2.3" and m=audio 45664 RTP/AVP 0" is not needed. But roughly speaking you are correct. Ciao Hannes > Is this correct? > > - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 08:55:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Rcb-0003vm-3Q; Sun, 24 Jun 2007 08:55:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2RcZ-0003ve-Qs for hipsec@ietf.org; Sun, 24 Jun 2007 08:55:15 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2RcY-0002En-Hd for hipsec@ietf.org; Sun, 24 Jun 2007 08:55:15 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I2Rcg-0007na-EL; Sun, 24 Jun 2007 08:55:22 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sun, 24 Jun 2007 08:55:16 -0400 To: Dan Wing , Hannes Tschofenig , Miika Komu , Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Dan Wing wrote (in a separate thread): > That said, I would really like to first concentrate on the *steps* > involved > in ICE, and how to make them work with HIP. Because that must > first be > agreed upon before we can reasonably discuss HIP parameter encoding. What I believe Dan means by the above is that we should first concentrate on the major design choices in a NAT traversal solution for HIP before worrying about the little details. And I totally agree with him. Here are what I see as the major design choices for a ICE-for-HIP design: 1) How (e.g., in what messages) are the ICE offer and answer conveyed? (Hannes and Dan are proposing the I2 and R2 messages; Miika is proposing the R1 and an Update message immediately after the Base Exchange). 2) What protocol is used for connectivity checks? (Hannes and Dan are proposing STUN; Miika is proposing HIP) 3) What is the general approach to encoding the Offer and Answer? (Hannes and Dan seem to be proposing using the existing text encoding; Miika is proposing a binary encoding using existing and new TLVs) 4) Do we follow ICE procedures exactly, or do we do some variations if they seem appropriate? (Hannes and Dan are proposing to follow the ICE procedures almost exactly; Miika is proposing a protocol that is ICE-like) 5) How do we integrate the security scheme of ICE with the security scheme of HIP? 6) How do we handle mobility? (Since this is something not really handled by ICE today) I suggest that a good way to proceed is to try to reach agreement on these design choices, before proposing a detailed proposal. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 09:07:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2RoT-00084A-4U; Sun, 24 Jun 2007 09:07:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2RoS-000845-FN for hipsec@ietf.org; Sun, 24 Jun 2007 09:07:32 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2RoR-0005rZ-8c for hipsec@ietf.org; Sun, 24 Jun 2007 09:07:32 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I2RoR-0004Eg-23; Sun, 24 Jun 2007 09:07:31 -0400 In-Reply-To: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59989D0A-58C9-4FDA-A636-086C1805C612@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sun, 24 Jun 2007 09:07:33 -0400 To: Dan Wing , Hannes Tschofenig , Miika Komu , Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 24-Jun-07, at 08:55 , Philip Matthews wrote: > > Here are what I see as the major design choices for a ICE-for-HIP > design: Let me add one other: 7) Do two HIP endpoints ALWAYS perform ICE, even if they have reasons to believe that they both have public addresses? (With SIP, the proposal is to always run ICE, partly because there is no sure way for an endpoint to tell when ICE is not needed, and partly because ICE brings advantages beyond NAT traversal: for example, selection of the best address to use when an endpoint is multihomed). - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 09:39:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SJH-0006EG-GK; Sun, 24 Jun 2007 09:39:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SJG-0006E8-6Q for hipsec@ietf.org; Sun, 24 Jun 2007 09:39:22 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2SJE-0002Ci-Qw for hipsec@ietf.org; Sun, 24 Jun 2007 09:39:22 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I2SJI-0004tA-FJ; Sun, 24 Jun 2007 09:39:24 -0400 In-Reply-To: <4234FDD1-CC6C-4F04-9A29-1556F75962C6@nomadiclab.com> References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> <4234FDD1-CC6C-4F04-9A29-1556F75962C6@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sun, 24 Jun 2007 09:39:20 -0400 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: 'HIP WG' , 'Hannes Tschofenig' Subject: [Hipsec] Re: Brief introduction to ICE X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 24-Jun-07, at 02:11 , Pekka Nikander wrote: > On 24 Jun 2007, at 05:05, Philip Matthews wrote: >> With ICE, the Offer and Answer include one or more "candidates". >> Each candidate is an (IP address, port, protocol) combination >> along with some related information. >> For example, the line >> a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >> specifies a UDP candidate with address 10.0.1.1 and port 8998, >> along with some other information. > > That kind of semantics is exactly why we made the HIP LOCATOR > parameter extensible. That is, the rationale back then was to be > able to encode not only IP addresses but more complex and variable > underlying addresses in a LOCATOR. For details, see Section 4 of > http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-05.txt > > Briefly, the LOCATOR carries one or more LOCATORS (candidates in > ICE), each with the > following format: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Traffic Type | Locator Type | Locator Length | > Reserved |P| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | Locator > Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > | > Locator | > > | | > > | | > > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > +-+-+ > > Currently only the following locator types are defined: > > 0: An IPv6 address or an IPv4-in-IPv6 format IPv4 address [8] > (128 > bits long). This locator type is defined primarily for non-ESP- > based usage. > > 1: The concatenation of an ESP SPI (first 32 bits) followed by an > IPv6 address or an IPv4-in-IPv6 format IPv4 address (an > additional > 128 bits). This IP address is defined primarily for ESP-based > usage. > > However, it would be trivial to define a new format for UDP > encapsulation; indeed, we had discussions about including it, but I > don't remember the details of that discussion any more. IIRC, back > then we decided to delay the definition of that format until the > NAT traversal discussions mature enough. This is the approach that Miika takes. He defines a new LOCATOR format for UDP encapsulation. > >> Using the Offer/Answer exchange, the two endpoints exchange sets >> of candidates. > > The HIP MM exchange allows the endpoints to exchange LOCATOR sets. Miika carries the Offer in the R1 packet, and the Answer in a Update packet, which I believe more-or-less corresponds to your proposal. However, I have some concerns with this approach, one of them being that I think it would be nice to keep the number of messages in the message exchange down. This is why I think we need a higher-level discussion of which messages are used to convey the Offer and the Answer. >> Each endpoint typically includes all the candidates that it knows >> about that can be used >> to reach it. These are both its private (address,port) >> combinations, as well as public >> (address,port) combinations which it learns by doing STUN >> BindingRequest/BindingResponse >> exchanges with a server. > > To me, this sounds like the exchange could trivially map to the HIP > mm exchange, but of course I may be completely wrong. > >> Each endpoint then forms all possible pairs of (local candidate, >> remote candidate), >> sorts these pairs in a defined way, and then performs connectivity >> checks to see >> if this pair can be used to communicate between the two endpoints. >> The connectivity >> checks are also performed using STUN messages. > > That sounds quite similar to the SHIM6 connectivity checks, to me. > See > http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure- > detection-08.txt I took a quick look at this document. There seems to be some ideas similar to ICE here, but they seem to be missing a number of ideas necessary for working with NATs. The most important is the concept of having the probe response return the address and port that it viewed the probe as having come from. (This is known as the peer-reflexive address). This is important when working with NATs that assign new address-and-port combinations to every destination. Also, ICE ordered the connectivity checks in a particular way, and requires that both endpoints use the same ordering. There are reasons to do this (though I have heard the argument that the recent ICE change to add Controlling and Controlled endpoints make this ordering much less important). And I don't understand why the Probe message in the SHIM6 document is so huge? Why include the "Nth probe sent" stuff? Or maybe I totally misunderstand the purpose of the Probe message. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 09:55:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SYy-0000jH-CZ; Sun, 24 Jun 2007 09:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SYx-0000j9-00 for hipsec@ietf.org; Sun, 24 Jun 2007 09:55:35 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2SYv-00058l-Iw for hipsec@ietf.org; Sun, 24 Jun 2007 09:55:34 -0400 Received: (qmail invoked by alias); 24 Jun 2007 13:55:29 -0000 Received: from p54985987.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.89.135] by mail.gmx.net (mp029) with SMTP; 24 Jun 2007 15:55:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX195QwgQpFp5X0xzwl6K9I6j7HUNkWtXsEr1i/Pc0W eru54wtuy+tzyU Message-ID: <467E77D0.6040701@gmx.net> Date: Sun, 24 Jun 2007 15:55:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [Hipsec] Re: Brief introduction to ICE References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> <4234FDD1-CC6C-4F04-9A29-1556F75962C6@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'HIP WG' , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Phillip, just a minor comment: ~snip~ >> That sounds quite similar to the SHIM6 connectivity checks, to me. See >> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt >> > > I took a quick look at this document. > There seems to be some ideas similar to ICE here, but they seem to be > missing > a number of ideas necessary for working with NATs. > The most important is the concept of having the probe response return the > address and port that it viewed the probe as having come from. > (This is known as the peer-reflexive address). This is important when > working > with NATs that assign new address-and-port combinations to every > destination. > Also, ICE ordered the connectivity checks in a particular way, and > requires that > both endpoints use the same ordering. There are reasons to do this > (though I have heard > the argument that the recent ICE change to add Controlling and > Controlled endpoints > make this ordering much less important). > And I don't understand why the Probe message in the SHIM6 document is > so huge? > Why include the "Nth probe sent" stuff? Or maybe I totally > misunderstand the purpose > of the Probe message. > This document is a good example of what happens if different groups in the IETF work independent of each other and they develop something similar twice. If you enhance this functionality to work in IPv4/IPv6 environments etc. then you will get (some time later) get close to the functionality of ICE/STUN (with the minor difference that ICE and STUN is already deployed today and none of the SHIM6 protocols is). Ciao Hannes > - Philip > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 09:56:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SZx-00011t-Pp; Sun, 24 Jun 2007 09:56:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SZt-00010k-Qg for hipsec@ietf.org; Sun, 24 Jun 2007 09:56:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2SZr-0005NN-U9 for hipsec@ietf.org; Sun, 24 Jun 2007 09:56:33 -0400 Received: (qmail invoked by alias); 24 Jun 2007 13:49:49 -0000 Received: from p54985987.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.89.135] by mail.gmx.net (mp039) with SMTP; 24 Jun 2007 15:49:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX196bAhaQLp6uPtNI48uky4DX3LxbINcEHpsYaVQC+ G+cR0JKGanXN/J Message-ID: <467E767C.6010100@gmx.net> Date: Sun, 24 Jun 2007 15:49:48 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Philip Matthews References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> <59989D0A-58C9-4FDA-A636-086C1805C612@magma.ca> In-Reply-To: <59989D0A-58C9-4FDA-A636-086C1805C612@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Phillip, Philip Matthews wrote: > > On 24-Jun-07, at 08:55 , Philip Matthews wrote: > >> >> Here are what I see as the major design choices for a ICE-for-HIP >> design: > > Let me add one other: > > 7) Do two HIP endpoints ALWAYS perform ICE, even if they have reasons > to believe > that they both have public addresses? > (With SIP, the proposal is to always run ICE, partly because there > is no sure > way for an endpoint to tell when ICE is not needed, and partly > because ICE > brings advantages beyond NAT traversal: for example, selection of > the best address > to use when an endpoint is multihomed). > Well, there is ICE lite. We suggest to make use of it if one of the end point knows for sure that it has global IP addresses and is not located behind a stateful packet filtering firewall or similar stuff. Ciao Hannes > - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 09:56:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SaA-0001pe-4R; Sun, 24 Jun 2007 09:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Sa9-0001pY-J4 for hipsec@ietf.org; Sun, 24 Jun 2007 09:56:49 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2Sa6-0005Sh-Q1 for hipsec@ietf.org; Sun, 24 Jun 2007 09:56:49 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I2Sa5-0006AA-1y; Sun, 24 Jun 2007 09:56:45 -0400 In-Reply-To: <467D79D2.90000@gmx.net> References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> <467D79D2.90000@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? Date: Sun, 24 Jun 2007 09:56:49 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'HIP WG' , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 23-Jun-07, at 15:51 , Hannes Tschofenig wrote: > I think that main point you raised is that you would like to have a > NAT that understands the HIP messages in the future and this > unfortunately impacts the current protocol design of the HIP- > unaware NAT traversal work. Personally speaking, I don't see NATs going away very soon (as much as I might like them too ;-), and even if they do, I think we will still have firewalls that implement the filtering concept of NATs today. So I think that making NATs HIP-aware is a much easier thing to make happen. So I personally think it is important that we work out a good story for how HIP-aware NATs work and make sure this integrates well with the rest of the NAT traversal for HIP work. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 09:58:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ScC-0004SL-NM; Sun, 24 Jun 2007 09:58:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2ScB-0004Pr-Ab for hipsec@ietf.org; Sun, 24 Jun 2007 09:58:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2ScA-0005km-QI for hipsec@ietf.org; Sun, 24 Jun 2007 09:58:55 -0400 Received: (qmail invoked by alias); 24 Jun 2007 13:52:13 -0000 Received: from p54985987.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.89.135] by mail.gmx.net (mp047) with SMTP; 24 Jun 2007 15:52:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180S8ZSEOA0/7Rd1CBiJ0d2c+ym6RFpotH9RVEtLX wC98TZOnwCEtXj Message-ID: <467E770C.5050308@gmx.net> Date: Sun, 24 Jun 2007 15:52:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Philip Matthews References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> In-Reply-To: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Phillip, a nice summary. Let me just add a minor detail: Philip Matthews wrote: > Dan Wing wrote (in a separate thread): >> That said, I would really like to first concentrate on the *steps* >> involved >> in ICE, and how to make them work with HIP. Because that must first be >> agreed upon before we can reasonably discuss HIP parameter encoding. > > What I believe Dan means by the above is that we should first > concentrate on the > major design choices in a NAT traversal solution for HIP before > worrying about the little details. > And I totally agree with him. > > > Here are what I see as the major design choices for a ICE-for-HIP design: > > 1) How (e.g., in what messages) are the ICE offer and answer conveyed? > (Hannes and Dan are proposing the I2 and R2 messages; Miika is > proposing the R1 and > an Update message immediately after the Base Exchange). > > 2) What protocol is used for connectivity checks? > (Hannes and Dan are proposing STUN; Miika is proposing HIP) > > 3) What is the general approach to encoding the Offer and Answer? > (Hannes and Dan seem to be proposing using the existing text encoding; > Miika is proposing a binary encoding using existing and new TLVs) > Actually, we wrote that we just use the current encoding unless someone is really excited about the few bits you could save. > 4) Do we follow ICE procedures exactly, or do we do some variations if > they seem appropriate? > (Hannes and Dan are proposing to follow the ICE procedures almost > exactly; > Miika is proposing a protocol that is ICE-like) > > 5) How do we integrate the security scheme of ICE with the security > scheme of HIP? > > 6) How do we handle mobility? > (Since this is something not really handled by ICE today) > Why do you think so? Mobility and multi-homing are just cases where a new candidate becomes available and others may become invalid (or may work again). Ciao Hannes > > I suggest that a good way to proceed is to try to reach agreement on > these design choices, > before proposing a detailed proposal. > > - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 10:10:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SnY-0007dx-HN; Sun, 24 Jun 2007 10:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SnU-0007dh-AA for hipsec@ietf.org; Sun, 24 Jun 2007 10:10:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2SnT-0008Q8-38 for hipsec@ietf.org; Sun, 24 Jun 2007 10:10:36 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1I2SnP-0008DO-Lu; Sun, 24 Jun 2007 10:10:31 -0400 In-Reply-To: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? Date: Sun, 24 Jun 2007 10:10:34 -0400 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: HIP WG , Hannes Tschofenig X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 23-Jun-07, at 13:31 , Dan Wing wrote: > > Two other things in your email I'm not worried about: (a) HIP- > aware NATs > having to parse the STUN messages and (b) demultiplexing STUN and HIP. I agree that demultiplexing STUN and HIP can be done reliably. (I wasn't actually worried about this). If we put the source and destination HITs into the USERNAME attribute (as you suggested), then building a HIP-aware NAT becomes more possible. However, wouldn't the NAT also have to store the transaction id, in order to route the BindingResponse message back to the endpoint, since the USERNAME attribute is not included in the BindingResponse message? Would this mean that the NAT would also have to duplicate the logic of the endpoint's STUN state machine, in order to figure out when it could forget the transaction id? What are the security implications of this? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 10:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SqE-0003WI-VE; Sun, 24 Jun 2007 10:13:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2SqE-0003WD-Ji for hipsec@ietf.org; Sun, 24 Jun 2007 10:13:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2SqD-0001L8-5n for hipsec@ietf.org; Sun, 24 Jun 2007 10:13:26 -0400 Received: (qmail invoked by alias); 24 Jun 2007 14:06:43 -0000 Received: from p54985987.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.89.135] by mail.gmx.net (mp010) with SMTP; 24 Jun 2007 16:06:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ErrhRLi+EqipJQs8f/XwXEAF0Fs9w7ysb4RLaxC ZJ7XO5zMFMHRWN Message-ID: <467E7A6F.2030002@gmx.net> Date: Sun, 24 Jun 2007 16:06:39 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> <467D79D2.90000@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'HIP WG' , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Phillip, I agree that it might be nice to have a NAT traversal story where the NAT participates in the exchange. Dan tried to have a BOF at the next IETF meeting to get this work for STUN, as you might know. A couple of us have tried to develop different protocols already that could interact with NATs and firewalls in order to control them. How many of them are deployed today? Not too many. You might want to look at a recently published document that tries to high-light some of the recent work in this field: http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-00.txt Let me tell you that the reason that these protocols are not widely deployed is non-technical. Hence, I am not so sure about the widespread deployment you might see. I do, however, agree with you that we are going to see NATs, stateful packet filtering firewalls and similar boxes hanging around probably for ever. Ciao Hannes PS: I have also contributed a document to the HIPRG on HIP-aware NAT traversal: http://www.tschofenig.com/svn/draft-tschofenig-hiprg-hip-natfw-traversal/draft-tschofenig-hiprg-hip-natfw-traversal-05.txt In earlier versions it also contained a solution but we removed that based on comments. In general the amount of feedback we got was pretty small. Hence, I wasn't quite sure whether that doc will ever get progressed to an RFC. Philip Matthews wrote: > > On 23-Jun-07, at 15:51 , Hannes Tschofenig wrote: > >> I think that main point you raised is that you would like to have a >> NAT that understands the HIP messages in the future and this >> unfortunately impacts the current protocol design of the HIP-unaware >> NAT traversal work. > > Personally speaking, I don't see NATs going away very soon (as much as > I might like them too ;-), and even if they do, I think we will still > have firewalls that implement the filtering concept of NATs today. So > I think that making NATs HIP-aware is a much easier thing to make happen. > > So I personally think it is important that we work out a good story > for how HIP-aware NATs work and make sure this integrates well with > the rest of the NAT traversal for HIP work. > > - Philip > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 10:22:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Sz8-00037l-UR; Sun, 24 Jun 2007 10:22:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Sz7-00037T-Ee for hipsec@lists.ietf.org; Sun, 24 Jun 2007 10:22:37 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2SuT-000255-44 for hipsec@lists.ietf.org; Sun, 24 Jun 2007 10:18:05 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1I2SuS-0001E7-KY; Sun, 24 Jun 2007 10:17:48 -0400 In-Reply-To: <467E2C9B.4060800@gmx.net> References: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> <7E115CCB-798C-474E-B78E-223D06311AF0@magma.ca> <467D4042.2050805@gmx.net> <284CAE3D-9E8F-419E-8400-C6B1C258B8E6@magma.ca> <467E2C9B.4060800@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] draft-tschofenig-hip-ice-00.txt Date: Sun, 24 Jun 2007 10:17:50 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: hipsec@lists.ietf.org, Hannes Tschofenig X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 24-Jun-07, at 04:34 , Hannes Tschofenig wrote: >> Let me make sure I understand what you mean. >> Here is the example SDP from section 4.3 of draft-ietf-mmusic- >> ice-16.txt >> >> v=0 >> o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1 >> s= >> c=IN IP4 192.0.2.3 >> t=0 0 >> a=ice-pwd:asd88fgpdd777uzjYhagZg >> a=ice-ufrag:8hhY >> m=audio 45664 RTP/AVP 0 >> b=RS:0 >> b=RR:0 >> a=rtpmap:0 PCMU/8000 >> a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >> a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx >> raddr 10.0.1.1 rport 8998 >> >> It sounds like your proposed HIP parameter would contain all the >> characters between the quote marks below: >> "c=IN IP4 192.0.2.3 >> a=ice-pwd:asd88fgpdd777uzjYhagZg >> a=ice-ufrag:8hhY >> m=audio 45664 RTP/AVP 0 >> a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host >> a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr >> 10.0.1.1 rport 8998" >> Here I have removed the "v=", "o=", "s=", "t=", and "b=" lines. >> Do you also remove the "m=" and "c=" lines? >> (these play an important role in ICE). >> > > ICE needs these attributes: > "candidate", > "remote-candidates", > "ice-lite", > "ice-mismatch", > "ice- ufrag", > "ice-pwd" > "ice-options" > > Hence, "c=IN IP4 192.0.2.3" and m=audio 45664 RTP/AVP 0" is not > needed. > > But roughly speaking you are correct. > Thanks! I understand your proposed attribute encoding now. Another question. The ICE spec talks a lot about manipulating the m and c lines in the SDP. It talks about putting a default candidate into m and c lines, how to choose that default candidate, and the need to re-offer if the selected valid pair does not match the values in the m and c lines in the original offer. How do you see all this working in ICE-for-HIP? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 10:28:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2T4s-0006Fi-Be; Sun, 24 Jun 2007 10:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2T4r-0006Fd-Tu for hipsec@ietf.org; Sun, 24 Jun 2007 10:28:33 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2T4q-0004hS-MH for hipsec@ietf.org; Sun, 24 Jun 2007 10:28:33 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I2T4x-0000Wg-DV; Sun, 24 Jun 2007 10:28:39 -0400 In-Reply-To: <467E767C.6010100@gmx.net> References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> <59989D0A-58C9-4FDA-A636-086C1805C612@magma.ca> <467E767C.6010100@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sun, 24 Jun 2007 10:28:34 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 24-Jun-07, at 09:49 , Hannes Tschofenig wrote: > Hi Phillip, > > Philip Matthews wrote: >> >> On 24-Jun-07, at 08:55 , Philip Matthews wrote: >> >>> >>> Here are what I see as the major design choices for a ICE-for-HIP >>> design: >> >> Let me add one other: >> >> 7) Do two HIP endpoints ALWAYS perform ICE, even if they have >> reasons to believe >> that they both have public addresses? >> (With SIP, the proposal is to always run ICE, partly because >> there is no sure >> way for an endpoint to tell when ICE is not needed, and partly >> because ICE >> brings advantages beyond NAT traversal: for example, selection >> of the best address >> to use when an endpoint is multihomed). >> > Well, there is ICE lite. We suggest to make use of it if one of the > end point knows for sure that it has global IP addresses and is not > located behind a stateful packet filtering firewall or similar stuff. My question was not so much about ICE vs ICE-lite, but more about existing HIP procedures vs. anything ICE-related. It was more: Do we see the existing HIP procedures being maintained for the situations where they work, or everything being redone with ICE in mind? There would be a lot of simplification if a HIP endpoint always followed the ICE procedures (or ICE-lite as you point out). Otherwise, there will be two rather different procedures, with no reliable way (other than configuration) to detect when the non-ICE procedures can be used. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 10:40:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2TGm-0008Ov-RM; Sun, 24 Jun 2007 10:40:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2TGl-0008N0-Ok for hipsec@ietf.org; Sun, 24 Jun 2007 10:40:51 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2TGX-0001uk-Fr for hipsec@ietf.org; Sun, 24 Jun 2007 10:40:51 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I2TGd-00020q-Fj; Sun, 24 Jun 2007 10:40:43 -0400 In-Reply-To: <467E770C.5050308@gmx.net> References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> <467E770C.5050308@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1447C005-3E12-4473-BDDE-E7972E087BFB@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sun, 24 Jun 2007 10:40:39 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 24-Jun-07, at 09:52 , Hannes Tschofenig wrote: > Hi Phillip, > > a nice summary. Thanks. And thank you for your draft, which helps by providing a view of an alternative approach which motivates this discussion. > Why do you think so? Mobility and multi-homing are just cases where > a new candidate becomes available and others may become invalid (or > may work again). The procedures in section 8.3. Freeing Candidates of the ICE spec state that a candidate should be freed up after 3 seconds if it is not selected for the media exchange. But in mobility situations, it might make sense to keep alternative candidates alive. Consider a mobile computer or phone which has both an 802.11 interface and a cellular interface. In the office, the computer should probably prefer the 802.11 interface. But what happens if the user is in the middle of a voice conversation or doing some similar real-time activity when he/she walks out of the building? Would it not be nice if ICE-for-HIP allowed the alternative of keeping the cellular path alive so traffic could switch to this path immediately without having to relocate the remote end and re-offer? Put another way -- HIP today just talks about a change in address. But I think we need to subdivide that into two cases: - Make-before-break cases where we add a new address before losing the old one, and - Break-before-make cases where we lose the old address before gaining a new one. I would like the first cases to have rapid handover. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 12:10:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2UfI-0003Ra-Lz; Sun, 24 Jun 2007 12:10:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2UfH-0003RH-D8 for hipsec@ietf.org; Sun, 24 Jun 2007 12:10:15 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2UfC-00031R-Rq for hipsec@ietf.org; Sun, 24 Jun 2007 12:10:15 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E7FD5212F45; Sun, 24 Jun 2007 19:10:08 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 50D7F212DAB; Sun, 24 Jun 2007 19:10:08 +0300 (EEST) In-Reply-To: References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? Date: Sun, 24 Jun 2007 19:10:05 +0300 To: Philip Matthews , Dan Wing , Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Phillip, Hannes, Dan, How are you planning to address security? Has anyone analysed the DoS/DDoS resistance properties of ICE/STUN? Personally, I don't see any point in making HIP to support other than fully HIP-aware and legacy NATs. For the HIP-aware case, I'd prefer if we could work out the NAT travesal in such a away that we could make the NATs to benefit from the DoS resistance of HIP and perhaps even DDoS resistance along some Hi3-like ideas. --Pekka On 24 Jun 2007, at 17:10, Philip Matthews wrote: > > On 23-Jun-07, at 13:31 , Dan Wing wrote: > >> >> Two other things in your email I'm not worried about: (a) HIP- >> aware NATs >> having to parse the STUN messages and (b) demultiplexing STUN and >> HIP. > > I agree that demultiplexing STUN and HIP can be done reliably. > (I wasn't actually worried about this). > > If we put the source and destination HITs into the USERNAME attribute > (as you suggested), then building a HIP-aware NAT becomes more > possible. > However, wouldn't the NAT also have to store the transaction id, > in order to route the BindingResponse message back to the endpoint, > since the USERNAME attribute is not included in the BindingResponse > message? > Would this mean that the NAT would also have to duplicate the logic > of the > endpoint's STUN state machine, in order to figure out when it could > forget > the transaction id? What are the security implications of this? > > - Philip > > > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun Jun 24 12:30:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Uyd-0004lP-Px; Sun, 24 Jun 2007 12:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Uyc-0004lK-Rd for hipsec@ietf.org; Sun, 24 Jun 2007 12:30:14 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2Uyc-0000Bv-9u for hipsec@ietf.org; Sun, 24 Jun 2007 12:30:14 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 72C7C212F45; Sun, 24 Jun 2007 19:30:13 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B9210212DAB; Sun, 24 Jun 2007 19:30:12 +0300 (EEST) In-Reply-To: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <63E1517C-F7AD-41D6-92C9-B91C92824F23@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Sun, 24 Jun 2007 19:30:10 +0300 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: HIP WG , Hannes Tschofenig , Hannes Tschofenig Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > What I believe Dan means by the above is that we should first > concentrate on the > major design choices in a NAT traversal solution for HIP before > worrying about the little details. > And I totally agree with him. Let me take a stab, though somewhat uninformed. I'm sorry if what I write below doesn't make any sense at all. > Here are what I see as the major design choices for a ICE-for-HIP > design: > > 1) How (e.g., in what messages) are the ICE offer and answer conveyed? > (Hannes and Dan are proposing the I2 and R2 messages; Miika is > proposing the R1 and > an Update message immediately after the Base Exchange). I don't have any good opinion here, since I don't understand what kind of semantics the choices would imply. For the record, in the past there has been discussions about whether to include LOCATOR parameters already into R1 (I think we rough consensus was that it could be allowed as an optional feature, though a risky one from a DDoS point of view), or whether to piggyback them into I2 and R2. See Section 3.2.9 of the M&M draft. http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-05.txt But, from the past discussion point of view, I think it might make sense to follow M&M. > 2) What protocol is used for connectivity checks? > (Hannes and Dan are proposing STUN; Miika is proposing HIP) This hasn't been addressed by HIP so far. Hence, based on your description I don't understand what Miika is proposing. For me, based on the information I've seen so far (and I may miss quite a lot), it would probably make most sense to encode STUN somehow within HIP. (I outlined some possibilities in a previous message.) > 3) What is the general approach to encoding the Offer and Answer? > (Hannes and Dan seem to be proposing using the existing text > encoding; > Miika is proposing a binary encoding using existing and new TLVs) From the code size point of view, binary TLVs, either existing ones, new ones, or ones adopted from STUN, would most probably make most sense. But there may be other aspects beyond the size and complexity of the code. Any implementors around, your opinions? > 4) Do we follow ICE procedures exactly, or do we do some variations > if they seem appropriate? > (Hannes and Dan are proposing to follow the ICE procedures > almost exactly; > Miika is proposing a protocol that is ICE-like) This one goes beyond my current understanding. > 5) How do we integrate the security scheme of ICE with the security > scheme of HIP? I'd be very interested to see someone explaining this in detail. I think this is one of the main issues. > 6) How do we handle mobility? > (Since this is something not really handled by ICE today) Mobility is pretty much handled by the M&M draft, though perhaps not fully for make-before-break or multi-homing situations. But, are there any good reasons to deviate from that draft? If there are, I'd like to here them explicitly. That draft has been around, in various forms, for three or four years and has received quite a lot of scrutiny. > 7) Do two HIP endpoints ALWAYS perform ICE, even if they have > reasons to believe > that they both have public addresses? > (With SIP, the proposal is to always run ICE, partly because > there is no sure > way for an endpoint to tell when ICE is not needed, and partly > because ICE > brings advantages beyond NAT traversal: for example, selection > of the best address > to use when an endpoint is multihomed). Something similar we have discussed several times in the past. My strong opinion has been that from an architectural point of view it would make most sense to try to run HIP directly, without UDP encapsulation, first. Or at least in parallel with the UDP- encapsulated exchange, in the case there are strong reasons to suspect that UDP-encapsulation is needed. The main rationality here is that from an architectural point of view UDP encapsulation should eventually disappear (maybe in 20 years or so), and we should *primarily* engineer our protocols for architectural cleanliness and flexibility, and only secondarily for optimality under current circumstances. In the past, idea in the HIP community has been to utilise the SHIM6 path diversity protocol to select the best address(es). But maybe ICE is better thought out, at least for the IPv4 NAT case. Anyway, as I said, perhaps the best way would be to draw the best ideas from both ICE and SHIM6, and try to combine them for a HIP- specific mobility, path diversity / multi-homing, and NAT traversal protocol. I think the M&M draft takes care of most of the mobility- specific stuff already, offers some initial hooks for multi-homing, and includes the LOCATOR parameter that was explicitly designed to allow NAT traversal. --Pekka Nikander _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 05:03:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2kTv-0000As-Nd; Mon, 25 Jun 2007 05:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2kTu-0000Ad-OE for hipsec@ietf.org; Mon, 25 Jun 2007 05:03:34 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2kTt-00042p-7T for hipsec@ietf.org; Mon, 25 Jun 2007 05:03:34 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 599ED2D12; Mon, 25 Jun 2007 12:03:32 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A2D112D0C; Mon, 25 Jun 2007 12:03:31 +0300 (EEST) Date: Mon, 25 Jun 2007 12:03:31 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Philip Matthews In-Reply-To: <498F4BCB-9FD7-4F0D-813A-289C6D9C0656@magma.ca> Message-ID: References: <498F4BCB-9FD7-4F0D-813A-289C6D9C0656@magma.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] Re: ICE-for-HIP design choice: STUN or HIP? X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 22 Jun 2007, Philip Matthews wrote: > Now that there are two competing proposals for how to do ICE-for-HIP: > http://tools.ietf.org/id/draft-ietf-hip-nat-traversal-01.txt > and > http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt > it seems to me that it would be good to step back for a moment and have a > discussion on some basic design choices. Discussing these individually would > help the design process, in my opinion. Just a reminder that the complete revised version has not submitted yet because there is still time to the submission DL. The revised version is here: http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre6.txt -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 06:06:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2lSg-0004zP-24; Mon, 25 Jun 2007 06:06:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2lSZ-0004vj-Qj for hipsec@ietf.org; Mon, 25 Jun 2007 06:06:15 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2lLM-0003ey-M3 for hipsec@ietf.org; Mon, 25 Jun 2007 05:58:50 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id F3FDD2D20; Mon, 25 Jun 2007 12:58:43 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 604DF2D12; Mon, 25 Jun 2007 12:58:42 +0300 (EEST) Date: Mon, 25 Jun 2007 12:58:42 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: "Tschofenig, Hannes" In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A407580218AA73@MCHP7IDA.ww002.siemens.net> Message-ID: References: <0D22E3C1A7D7A843B12BF8C6F0A407580218AA73@MCHP7IDA.ww002.siemens.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1483920592-1182765522=:17560" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: HIP WG , Philip Matthews Subject: [Hipsec] Re: AW: ICE-for-HIP design choice: STUN or HIP? X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1483920592-1182765522=:17560 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On Mon, 25 Jun 2007, Tschofenig, Hannes wrote: Andrei wanted to participate to the draft, but unfortunately he didn't have time. We agreed that I will continue as the editor. > Is the only change in the document that it now has a new editor, Andrei= =20 > Gurtov? > > Ciao > Hannes > >> -----Urspr=FCngliche Nachricht----- >> Von: ext Miika Komu [mailto:miika@iki.fi] >> Gesendet: Montag, 25. Juni 2007 11:04 >> An: Philip Matthews >> Cc: Dan Wing; Tschofenig, Hannes; HIP WG >> Betreff: Re: ICE-for-HIP design choice: STUN or HIP? >> >> On Fri, 22 Jun 2007, Philip Matthews wrote: >> >>> Now that there are two competing proposals for how to do >> ICE-for-HIP: >>> http://tools.ietf.org/id/draft-ietf-hip-nat-traversal-01.txt >>> and >>> >> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt >>> it seems to me that it would be good to step back for a >> moment and have a >>> discussion on some basic design choices. Discussing these >> individually would >>> help the design process, in my opinion. >> >> Just a reminder that the complete revised version has not >> submitted yet >> because there is still time to the submission DL. The revised >> version is >> here: >> >> http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre6.txt >> >> -- >> Miika Komu >> http://www.iki.fi/miika/ >> > --=20 Miika Komu http://www.iki.fi/miika/ ---559023410-1483920592-1182765522=:17560 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec ---559023410-1483920592-1182765522=:17560-- From hipsec-bounces@lists.ietf.org Mon Jun 25 07:42:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2mxn-0001hZ-9w; Mon, 25 Jun 2007 07:42:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2mxl-0001hR-TS for hipsec@lists.ietf.org; Mon, 25 Jun 2007 07:42:33 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2mxk-0004la-Ch for hipsec@lists.ietf.org; Mon, 25 Jun 2007 07:42:33 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id C5EA52D0C; Mon, 25 Jun 2007 14:42:27 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 0A79C2C5D; Mon, 25 Jun 2007 14:42:26 +0300 (EEST) Date: Mon, 25 Jun 2007 14:42:26 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing In-Reply-To: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> Message-ID: References: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org Subject: [Hipsec] Re: draft-tschofenig-hip-ice-00.txt X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 22 Jun 2007, Dan Wing wrote: Hi, seems like the discussion exploded during weekend. Answering to rest of the emails after this, but first few overall comments on the draft: The draft is missing flow graphs which makes it immensily difficult to understand how the protocol actually works. Particularly, I am interested in seeing all of the following things in flow diagrams: * Registration to RVS * Relaying of the base exchange through the RVS * Reachability detection * Handover with reachability detection After you have unblurred this information to the draft, we can compare the RTT between the drafts, which I think is generally larger in draft-tschofenig-hip-ice. I did not understand the state requirements for the RVS after a quick read: * Does the RVS forward all HIP control packets? * Does the RVS impose state towards the Initiator (aka "L") For draft-ietf-hip-nat-traversal-02-pre6, the answer to the first question is "yes" to provide 100 % reliability over legacy NATs. The answer to the second question is "no" to avoid DoSing or overloading the RVS server. > This document explains how we see ICE and HIP could work together. Comments > welcome. > > -d > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Utilizing Interactive Connectivity >> Establishment (ICE) for the Host Identity Protocol (HIP) >> Author(s) : H. Tschofenig, D. Wing >> Filename : draft-tschofenig-hip-ice-00.txt >> Pages : 22 >> Date : 2007-6-22 >> >> >> This document describes how the Interactive Connectivity >> Establishment (ICE) methodology can be used for the Host Identity >> Protocol (HIP) to determine whether end-to-end communication is >> possible. ICE makes use of the Session Traversal Utilities for NAT >> (STUN) protocol in addition to mechanisms for checking connectivity >> between peers. After running the ICE the two HIP end >> points will be >> able to communicate directly or through a relay via Network Address >> Translators (NATs), Network Address and Port Translators >> (NAPTs) and >> firewalls . >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in >> the body of >> the message. >> You can also visit >> https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username "anonymous" and a password of your e-mail address. After >> logging in, type "cd internet-drafts" and then >> "get draft-tschofenig-hip-ice-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-tschofenig-hip-ice-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >> mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n2A-0002f5-AA; Mon, 25 Jun 2007 07:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n29-0002ez-Bb for hipsec@ietf.org; Mon, 25 Jun 2007 07:47:05 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n28-0005Av-0w for hipsec@ietf.org; Mon, 25 Jun 2007 07:47:05 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 8584A2D0C; Mon, 25 Jun 2007 14:47:03 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id EB2B42CE5; Mon, 25 Jun 2007 14:47:02 +0300 (EEST) Date: Mon, 25 Jun 2007 14:47:02 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Philip Matthews In-Reply-To: <498F4BCB-9FD7-4F0D-813A-289C6D9C0656@magma.ca> Message-ID: References: <498F4BCB-9FD7-4F0D-813A-289C6D9C0656@magma.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: HIP WG , Hannes Tschofenig Subject: [Hipsec] Re: ICE-for-HIP design choice: STUN or HIP? X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 22 Jun 2007, Philip Matthews wrote: > Here is what I see as being the pros and cons of the two approaches: > > STUN: > + Protocol is already defined and deployed. > > The first is the question of deployment. STUN is currently deployed today, so > there are STUN servers that a HIP node could use. But is this really > important? If we build enhanced HIP functionality into HIP and into RVSes, > then I think there will always be a public server around that a HIP node > could use to discover its reflexive address. The use of a HIP-aware middlebox in reliable legacy NAT traversal is mandatory. If there is no HIP-aware middlebox, HIP NAT traversal cannot be guaranteed. Thus, a host at least one HIP-aware middlebox for successful NAT traversal. The middlebox can also server as a STUN-like server, so there is not much other benefit from STUN servers other than to provide redundant support for NAT detection. It is also possible for the HIP middlebox to borrow bindings using regular STUN from regular STUN servers and communicate these to the client. > But how does this work if we use STUN instead? In this case, the packet > would consist of a STUN message riding directly over IP (but where the > IP protocol field would specify HIP rather than STUN). In order for the > NAT to create the appropriate bindings, the STUN message would need to > contain the source and destination HITs somewhere in the message. The > only place to carry these in STUN is in some STUN attribute. So this > means that the NAT has to be able to do a fairly complete parse of a > STUN message. > > Requiring a HIP-aware NAT to do a fairly complete parse of a STUN message > concerns me a bit. It seems quite unnatural to me. Agree. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:47:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n2O-0002pm-RQ; Mon, 25 Jun 2007 07:47:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n2O-0002ph-9P for hipsec@ietf.org; Mon, 25 Jun 2007 07:47:20 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n2N-0005CA-0i for hipsec@ietf.org; Mon, 25 Jun 2007 07:47:20 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 911782D12; Mon, 25 Jun 2007 14:47:18 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1369C2CF8; Mon, 25 Jun 2007 14:47:18 +0300 (EEST) Date: Mon, 25 Jun 2007 14:47:18 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing In-Reply-To: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> Message-ID: References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'HIP WG' , 'Hannes Tschofenig' , 'Philip Matthews' Subject: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Sat, 23 Jun 2007, Dan Wing wrote: > The important difference with draft-tschofenig-hip-ice isn't the > encoding on-the-wire. Disagree. I think the debate is exactly about the format on the wire, see below. > Rather, the important difference is performing ICE. Those steps > are: > > Initiator: > * gather candidate addresses > * send candidate addresses to remote peer (terminator) > via a rendezvous protocol (HIP, in this case; SIP in > the traditional case of ICE) > > Terminator: > * gather its own candidate addresses > * perform connectivity checks with the remote peer > (initiator) to find a functional path to the initiator > * send candidate addresses to remote peer (initiator) via > a rendezvous protocol (HIP) > > Initiator: > * perform connectivity checks with the remote peer > (terminator) > * prioritize successful checks and determine which path > is preferred (for example: avoid UDP encapsulation, > take a path over only HIP-aware NATs if that's desirable, > avoid NATs and take direct path, etc.). This choice is > communicated to the remote peer (terminator), so it can > make the same choice so bi-directional traffic can be > assured (which is necessary to keep all the NATs open). This functionality is already available in draft-ietf-hip-nat-traversal-02-pre6.txt, so I would insist that the debate is about the format-on-the-wire. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:50:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n58-000367-Qa; Mon, 25 Jun 2007 07:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n56-00035r-Bv for hipsec@lists.ietf.org; Mon, 25 Jun 2007 07:50:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2n54-0005UU-Sg for hipsec@lists.ietf.org; Mon, 25 Jun 2007 07:50:08 -0400 Received: (qmail invoked by alias); 25 Jun 2007 11:50:05 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp036) with SMTP; 25 Jun 2007 13:50:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19DgMYQcMJDtGrxVxFlZi/pBDwh7EobrP3/RuQ1HG g9mxs3YScYV1IZ Message-ID: <467FABEC.4010801@gmx.net> Date: Mon, 25 Jun 2007 13:50:04 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] Re: draft-tschofenig-hip-ice-00.txt References: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Miika, as with NAT traversal in SIP the traversal over RVS and the registration at the RVS is not subject to the draft. That's a different problem. Ciao Hannes Miika Komu wrote: > On Fri, 22 Jun 2007, Dan Wing wrote: > > Hi, > > seems like the discussion exploded during weekend. Answering to rest > of the emails after this, but first few overall comments on the draft: > > The draft is missing flow graphs which makes it immensily difficult to > understand how the protocol actually works. Particularly, I am > interested in seeing all of the following things in flow diagrams: > > * Registration to RVS > * Relaying of the base exchange through the RVS > * Reachability detection > * Handover with reachability detection > > After you have unblurred this information to the draft, we can compare > the RTT between the drafts, which I think is generally larger in > draft-tschofenig-hip-ice. > > I did not understand the state requirements for the RVS after a quick > read: > > * Does the RVS forward all HIP control packets? > * Does the RVS impose state towards the Initiator (aka "L") > > For draft-ietf-hip-nat-traversal-02-pre6, the answer to the first > question is "yes" to provide 100 % reliability over legacy NATs. The > answer to the second question is "no" to avoid DoSing or overloading > the RVS server. > >> This document explains how we see ICE and HIP could work together. >> Comments >> welcome. >> >> -d >> >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Utilizing Interactive Connectivity >>> Establishment (ICE) for the Host Identity Protocol (HIP) >>> Author(s) : H. Tschofenig, D. Wing >>> Filename : draft-tschofenig-hip-ice-00.txt >>> Pages : 22 >>> Date : 2007-6-22 >>> >>> >>> This document describes how the Interactive Connectivity >>> Establishment (ICE) methodology can be used for the Host Identity >>> Protocol (HIP) to determine whether end-to-end communication is >>> possible. ICE makes use of the Session Traversal Utilities for NAT >>> (STUN) protocol in addition to mechanisms for checking connectivity >>> between peers. After running the ICE the two HIP end >>> points will be >>> able to communicate directly or through a relay via Network Address >>> Translators (NATs), Network Address and Port Translators >>> (NAPTs) and >>> firewalls . >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in >>> the body of >>> the message. >>> You can also visit >>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> Internet-Drafts are also available by anonymous FTP. Login with the >>> username "anonymous" and a password of your e-mail address. After >>> logging in, type "cd internet-drafts" and then >>> "get draft-tschofenig-hip-ice-00.txt". >>> >>> A list of Internet-Drafts directories can be found in >>> http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> Internet-Drafts can also be obtained by e-mail. >>> >>> Send a message to: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-tschofenig-hip-ice-00.txt". >>> >>> NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant >>> mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >> > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:51:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n6N-0003ZL-UQ; Mon, 25 Jun 2007 07:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n6M-0003Z7-NY for hipsec@ietf.org; Mon, 25 Jun 2007 07:51:26 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n6M-0005aQ-5l for hipsec@ietf.org; Mon, 25 Jun 2007 07:51:26 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id B54AA2D12; Mon, 25 Jun 2007 14:51:25 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 1302C2CEE; Mon, 25 Jun 2007 14:51:25 +0300 (EEST) Date: Mon, 25 Jun 2007 14:51:25 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Philip Matthews In-Reply-To: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> Message-ID: References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: HIP WG , Hannes Tschofenig , Hannes Tschofenig Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Sun, 24 Jun 2007, Philip Matthews wrote: > Dan Wing wrote (in a separate thread): > >> That said, I would really like to first concentrate on the *steps* involved >> in ICE, and how to make them work with HIP. Because that must first be >> agreed upon before we can reasonably discuss HIP parameter encoding. > > What I believe Dan means by the above is that we should first > concentrate on the major design choices in a NAT traversal solution for > HIP before worrying about the little details. And I totally agree with > him. Both drafts are based on ICE, so I still think that the encoding is the main issue here. But ok, let's concentrate on the high level design issues of the encodings instead of worrying about the bits yet. Also, regarding to the design choices, I would like to remind the draft-tschofenig-hip-ice-00 authors to show some flow diagrams in their draft. The current draft only considers mostly about protocol encodings and showing the diff between ICE. high-level operation is still very blurry in the draft. > Here are what I see as the major design choices for a ICE-for-HIP design: > > 1) How (e.g., in what messages) are the ICE offer and answer conveyed? > (Hannes and Dan are proposing the I2 and R2 messages; Miika is proposing > the R1 and > an Update message immediately after the Base Exchange). I have no strong opinion of moving the LOCATOR from the R1 to the R2. The drawback is the "incompatibility" with draft-hip-mm, but the benefit would be in terms of monetary cost. We briefly discussed the topic with Philip last week and the credit for the idea really belongs to him. To explain the motivation for this, let's consider a multihomable Responder with two NATted interfaces. The first interface is a "free", but unstable WLAN interface, and the second is a "hi-cost", stable cellural interface. The Responder normally keeps only the WLAN interface up because it does not want to pay for the NAT keepalives. However, the responder may activate also the cellular interaface and its costful NAT keepalives, but only upon receiving a high-priority HIP connection (based on Initiator HIT). If the secondary interface is activated upon receiving I1, the Responder is subject to costful DoS because it is trivial to forge I1 packets. However, the situation is better when the secondary interface is activated upon receiving the I2. The I2 packet is protected using a signature and it even contains the solution of the puzzle. Now, the Responder can activate the secondary interface and send the related information in R2. Comments? > 3) What is the general approach to encoding the Offer and Answer? > (Hannes and Dan seem to be proposing using the existing text encoding; > Miika is proposing a binary encoding using existing and new TLVs) Text encoding takes too much space and fragmentation of HIP packets should be avoided to reduce RTT. The UDP header already eats some bits. If we use text encoding, we may end-up introducing silly compression methods in later standards. > 6) How do we handle mobility? > (Since this is something not really handled by ICE today) draft-ietf-hip-nat-traversal-02-pre6 describes mobility in terms of draft-mm UPDATE handover (LOCATOR, ECHO_REQUEST, RESPONSE). The reachability detection is basically a handover. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:51:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n6W-0003da-Ek; Mon, 25 Jun 2007 07:51:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n6U-0003dL-WA for hipsec@ietf.org; Mon, 25 Jun 2007 07:51:35 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2n6U-0005b0-Js for hipsec@ietf.org; Mon, 25 Jun 2007 07:51:34 -0400 Received: (qmail invoked by alias); 25 Jun 2007 11:51:33 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp043) with SMTP; 25 Jun 2007 13:51:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX198F3ZTqKB83yz2jdU3gbxNTxHONtcCK04GmdSw7U IXgUk3HZbVajto Message-ID: <467FAC44.8050502@gmx.net> Date: Mon, 25 Jun 2007 13:51:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] Re: ICE-for-HIP design choice: STUN or HIP? References: <498F4BCB-9FD7-4F0D-813A-289C6D9C0656@magma.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: HIP WG , Hannes Tschofenig , Philip Matthews X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org What do you mean by "The use of a HIP-aware middlebox in reliable legacy NAT traversal is mandatory."? A HIP aware middlebox is a NAT or a firewall that understands HIP. None of the drafts in the HIP working group address that topic. Ciao Hannes Miika Komu wrote: > On Fri, 22 Jun 2007, Philip Matthews wrote: > >> Here is what I see as being the pros and cons of the two approaches: >> >> STUN: >> + Protocol is already defined and deployed. >> >> The first is the question of deployment. STUN is currently deployed >> today, so there are STUN servers that a HIP node could use. But is >> this really important? If we build enhanced HIP functionality into >> HIP and into RVSes, then I think there will always be a public server >> around that a HIP node could use to discover its reflexive address. > > The use of a HIP-aware middlebox in reliable legacy NAT traversal is > mandatory. If there is no HIP-aware middlebox, HIP NAT traversal > cannot be guaranteed. Thus, a host at least one HIP-aware middlebox > for successful NAT traversal. The middlebox can also server as a > STUN-like server, so there is not much other benefit from STUN servers > other than to provide redundant support for NAT detection. > > It is also possible for the HIP middlebox to borrow bindings using > regular STUN from regular STUN servers and communicate these to the > client. > >> But how does this work if we use STUN instead? In this case, the >> packet would consist of a STUN message riding directly over IP (but >> where the IP protocol field would specify HIP rather than STUN). In >> order for the NAT to create the appropriate bindings, the STUN >> message would need to contain the source and destination HITs >> somewhere in the message. The only place to carry these in STUN is in >> some STUN attribute. So this means that the NAT has to be able to do >> a fairly complete parse of a STUN message. >> >> Requiring a HIP-aware NAT to do a fairly complete parse of a STUN >> message >> concerns me a bit. It seems quite unnatural to me. > > Agree. > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:51:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n6d-0003qs-ML; Mon, 25 Jun 2007 07:51:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n6c-0003mp-4l for hipsec@ietf.org; Mon, 25 Jun 2007 07:51:42 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n6a-0005bZ-Qf for hipsec@ietf.org; Mon, 25 Jun 2007 07:51:42 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 57D982D18; Mon, 25 Jun 2007 14:51:40 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 037622D0C; Mon, 25 Jun 2007 14:51:38 +0300 (EEST) Date: Mon, 25 Jun 2007 14:51:37 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Hannes Tschofenig In-Reply-To: <467E767C.6010100@gmx.net> Message-ID: References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> <59989D0A-58C9-4FDA-A636-086C1805C612@magma.ca> <467E767C.6010100@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: HIP WG , Hannes Tschofenig , Philip Matthews Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Sun, 24 Jun 2007, Hannes Tschofenig wrote: > Hi Phillip, > > Philip Matthews wrote: >> >> On 24-Jun-07, at 08:55 , Philip Matthews wrote: >> >>> >>> Here are what I see as the major design choices for a ICE-for-HIP design: >> >> Let me add one other: >> >> 7) Do two HIP endpoints ALWAYS perform ICE, even if they have reasons to >> believe >> that they both have public addresses? >> (With SIP, the proposal is to always run ICE, partly because there is no >> sure >> way for an endpoint to tell when ICE is not needed, and partly because >> ICE >> brings advantages beyond NAT traversal: for example, selection of the >> best address >> to use when an endpoint is multihomed). >> > Well, there is ICE lite. We suggest to make use of it if one of the end point > knows for sure that it has global IP addresses and is not located behind a > stateful packet filtering firewall or similar stuff. This is addressed in draft-ietf-hip-nat-traversal-02-pre6: 3.4. Connectivity Tests There is no relay when the RELAY_TO parameters are not present. In this case, the hosts SHOULD allow the transmission of ESP traffic even though the base exchange is sent over the transport layer. A possible scenario where this can occur is when the Initiator is behind a NAT and Responder is located in a public network. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:52:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n72-00046G-6a; Mon, 25 Jun 2007 07:52:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n70-0003zk-S8 for hipsec@ietf.org; Mon, 25 Jun 2007 07:52:06 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n6y-0005dA-Hu for hipsec@ietf.org; Mon, 25 Jun 2007 07:52:06 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1BC642D12; Mon, 25 Jun 2007 14:52:04 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9164B2CE5; Mon, 25 Jun 2007 14:52:02 +0300 (EEST) Date: Mon, 25 Jun 2007 14:52:02 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Hannes Tschofenig In-Reply-To: <467E770C.5050308@gmx.net> Message-ID: References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> <467E770C.5050308@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: HIP WG , Hannes Tschofenig , Philip Matthews Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Sun, 24 Jun 2007, Hannes Tschofenig wrote: >> 3) What is the general approach to encoding the Offer and Answer? >> (Hannes and Dan seem to be proposing using the existing text encoding; >> Miika is proposing a binary encoding using existing and new TLVs) >> > Actually, we wrote that we just use the current encoding unless someone is > really excited about the few bits you could save. I am. I don't like fragmentation. > 6) How do we handle mobility? > (Since this is something not really handled by ICE today) > > Why do you think so? Mobility and multi-homing are just cases where a new > candidate becomes available and others may become invalid (or may work > again). ICE draft does not define how to handle end-host mobility and the security challenges related to mobility. How does the mobility in your draft integrate with regular draft-mm mobility? -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:52:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n7C-0004hB-H5; Mon, 25 Jun 2007 07:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n7A-0004ai-Vi for hipsec@ietf.org; Mon, 25 Jun 2007 07:52:17 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n7A-0005dh-GC for hipsec@ietf.org; Mon, 25 Jun 2007 07:52:16 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 110582D12; Mon, 25 Jun 2007 14:52:16 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5452E2CE5; Mon, 25 Jun 2007 14:52:15 +0300 (EEST) Date: Mon, 25 Jun 2007 14:52:15 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander In-Reply-To: <176780D8-F5C6-4235-8AAB-D14F5C19BE52@nomadiclab.com> Message-ID: References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> <999BE24F-525B-48A7-BA3A-C2A115D74DAD@magma.ca> <176780D8-F5C6-4235-8AAB-D14F5C19BE52@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: HIP WG , Hannes Tschofenig , Philip Matthews Subject: [Hipsec] Re: Brief introduction to STUN X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Sun, 24 Jun 2007, Pekka Nikander wrote: Pekka, draft-ietf-hip-nat-traversal-02-pre6 already contains the HIP parameters that you talking about, such as REG_REQ of type "BindingRequest". The draft also contains path exploration similar to SHIM6 although I have to improve that part. > Therefore, mapping STUN Attributes to HIP Parameters should be a trivial > task: > > 1. Define a mapping of Type values, if needed. Of course, if an > equality-based mapping would work, that would be excellent, but I doubt. > > 2. Use the HIP Length computation method in order to make the handling of all > HIP parameters, including those based on STUN, to use the same method. > > 3. Use the STUN definition for Value as the HIP Contents. > > Though, for some Attributes it might be better to use already defined HIP > equivalents. For example, I could imagine that it would make sense to use > HIP Sequence Number and Acknowledgement parameters. And as already discussed > in my previous message, for ICE candidates it would probably be better to use > the HIP LOCATOR parameter, extended in a suitable way to encode the required > locator formats in a sensible way. > > One benefit here might be that HIP contains mechanisms that can be used to > allow "transactions" to overlap. > >> ICE uses STUN in two different ways: >> >> 1) To determine the public address and port that a NAT has allocated >> that corresponds to the private address and port of an endpoint. >> To do this, an endpoint sends a STUN BindingRequest message to a server >> on the public Internet, which replies with a BindingResponse message. > > This could be mapped on the top of the HIP (RVS) Registration protocol. > The BindingRequest (or equivalent info mapped on the Registration protocol) > could be carried in a REG_REQ Parameter, or next to it. > > Hence, I see here two choices: > > 1. Simply carry BindingRequest as an additional parameter wherever you carry > a REG_REQ parameter, or > 2. Map the BindingRequest into an equivalent HIP REG_REQ parameter. > >> The server places the source address and port it saw in the received >> UDP message into an attribute in the BindingResponse message. >> In this way, the endpoint learns the public address and port that the >> NAT has assigned it. > > Here there might be three different design choices: > 1. Simply carry BindingResponse in any message responding to a previous > message carring a BindingRequest. > 2. Define a REQ_RES extension that carries the information in > BindingResponse. > 3. Define a variant of LOCATOR that carries the information in > BindingResponse. > > Of course, there might be other sensible alternatives in both cases. > >> 2) To determine if two endpoints can communicate using a given 5-type >> of (source IP address, source port, dest IP address, dest port, protocol). >> To do this, both endpoints send STUN BindingRequest messages to each other >> using the 5-tuple. If an end gets a response, it knows that the 5-tuple >> works. > > As an initial approximiation, I think that a variant of the HIP MM protocol, > drawing from the ICE experience and SHIM6 exploration formats, might be the > best way forward. But here I might be completely wrong; there seems to be > subtleties that I don't understand. > > My main point here is that NAT such exploration should not be limited to the > NAT traversal case but should allow any two HIP hosts to explore the > characteristics of all paths, independent of whether the paths are based on > IPv4, IPv6, and contain no, transparent, or explicit middle boxes. From my > point of view, most of the required components for such a mechanism are > already there scattered over the various HIP drafts; what is missing is the > algorithms and state machine definitions for utilising them. But perhaps I'm > too simple minded here. > > --Pekka -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:52:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n7N-0005To-HP; Mon, 25 Jun 2007 07:52:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n7K-0005Eo-BC for hipsec@ietf.org; Mon, 25 Jun 2007 07:52:26 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n7J-0005eJ-1I for hipsec@ietf.org; Mon, 25 Jun 2007 07:52:26 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 96FD82D0C; Mon, 25 Jun 2007 14:52:24 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 29B3E2CE5; Mon, 25 Jun 2007 14:52:24 +0300 (EEST) Date: Mon, 25 Jun 2007 14:52:24 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Philip Matthews Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? In-Reply-To: Message-ID: References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <0EAC6D2A-637A-49A4-A11D-65177CDD0BF2@nomadiclab.com> <467D79D2.90000@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 'HIP WG' , Hannes Tschofenig , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Sun, 24 Jun 2007, Philip Matthews wrote: > So I personally think it is important that we work out a good story for how > HIP-aware NATs work and make sure this integrates well with the rest of the > NAT traversal for HIP work. In draft-ietf-hip-nat-traversal-02-pre6, the story is that the NAT hosts send also non-UDP encapsulated messages to peers (unreflexive, reflexive peer and relay locators). Text needs some improving regarding to this. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:53:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n8D-0006co-Qf; Mon, 25 Jun 2007 07:53:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n8C-0006cd-NS for hipsec@ietf.org; Mon, 25 Jun 2007 07:53:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2n8A-0005gT-Ag for hipsec@ietf.org; Mon, 25 Jun 2007 07:53:20 -0400 Received: (qmail invoked by alias); 25 Jun 2007 11:53:17 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp028) with SMTP; 25 Jun 2007 13:53:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+RTn5cMEqREnPVlb1fPfN1GCs5NAQLwpptQ6n5y2 Wxya5WjtbJfCcz Message-ID: <467FACAB.9070903@gmx.net> Date: Mon, 25 Jun 2007 13:53:15 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'HIP WG' , 'Hannes Tschofenig' , 'Philip Matthews' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Miika Miika Komu wrote: > On Sat, 23 Jun 2007, Dan Wing wrote: > >> The important difference with draft-tschofenig-hip-ice isn't the >> encoding on-the-wire. > > Disagree. I think the debate is exactly about the format on the wire, > see below. > The encoding of the candidates that are exchanged is not really so important. The concept is important and to make use of work that was done elsewhere is (rather than reinventing the wheel). >> Rather, the important difference is performing ICE. Those steps >> are: >> >> Initiator: >> * gather candidate addresses >> * send candidate addresses to remote peer (terminator) >> via a rendezvous protocol (HIP, in this case; SIP in >> the traditional case of ICE) >> >> Terminator: >> * gather its own candidate addresses >> * perform connectivity checks with the remote peer >> (initiator) to find a functional path to the initiator >> * send candidate addresses to remote peer (initiator) via >> a rendezvous protocol (HIP) >> >> Initiator: >> * perform connectivity checks with the remote peer >> (terminator) >> * prioritize successful checks and determine which path >> is preferred (for example: avoid UDP encapsulation, >> take a path over only HIP-aware NATs if that's desirable, >> avoid NATs and take direct path, etc.). This choice is >> communicated to the remote peer (terminator), so it can >> make the same choice so bi-directional traffic can be >> assured (which is necessary to keep all the NATs open). > > This functionality is already available in > draft-ietf-hip-nat-traversal-02-pre6.txt, so I would insist that the > debate is about the format-on-the-wire. > Ciao Hannes _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 07:53:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n8p-0006kw-CH; Mon, 25 Jun 2007 07:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n8o-0006kq-0v for hipsec@ietf.org; Mon, 25 Jun 2007 07:53:58 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n8n-0005j4-Ey for hipsec@ietf.org; Mon, 25 Jun 2007 07:53:58 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 053E02CE5; Mon, 25 Jun 2007 14:53:56 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 239502CE5; Mon, 25 Jun 2007 14:53:56 +0300 (EEST) Date: Mon, 25 Jun 2007 14:53:56 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander In-Reply-To: <63E1517C-F7AD-41D6-92C9-B91C92824F23@nomadiclab.com> Message-ID: References: <864EA8A8-61B5-4E70-982B-9A5CEB9D3CAF@magma.ca> <63E1517C-F7AD-41D6-92C9-B91C92824F23@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: HIP WG , Hannes Tschofenig , Hannes Tschofenig , Philip Matthews Subject: [Hipsec] Re: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Sun, 24 Jun 2007, Pekka Nikander wrote: > I don't have any good opinion here, since I don't understand what kind of > semantics the choices would imply. > > For the record, in the past there has been discussions about whether to > include LOCATOR parameters already into R1 (I think we rough consensus was > that it could be allowed as an optional feature, though a risky one from a > DDoS point of view), or whether to piggyback them into I2 and R2. See > Section 3.2.9 of the M&M draft. > http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-05.txt > > But, from the past discussion point of view, I think it might make sense to > follow M&M. I believe the main reason why the LOCATOR is in R1 is that the Responder can "force" the Initiator to switch immediately to an alternative address already in I2. However, this cannot be applied to NAT traversal because reachability detection for working addresss pairs must be done first. Tom, can you comment this? >> 2) What protocol is used for connectivity checks? >> (Hannes and Dan are proposing STUN; Miika is proposing HIP) > > This hasn't been addressed by HIP so far. Hence, based on your > description I don't understand what Miika is proposing. For me, based > on the information I've seen so far (and I may miss quite a lot), it > would probably make most sense to encode STUN somehow within HIP. (I > outlined some possibilities in a previous message.) The connectivity tests are done after a base exchange or a handover (both relayed through RVS over UDP). We are proposing to trigger the reachability detection using HIP UPDATE. This is followed by ECHO REQUEST and RESPONSE messages that do the UDP hole punching and verify address reachability as in draft-hip-mm. Philip also asked if we could send the I2 message with NATted LOCATORs for triggering the connectivity tests. This would save one packet transmission, but the trigger mechanism would be different for base exchange and mobility. >> 3) What is the general approach to encoding the Offer and Answer? >> (Hannes and Dan seem to be proposing using the existing text encoding; >> Miika is proposing a binary encoding using existing and new TLVs) > > From the code size point of view, binary TLVs, either existing ones, new > ones, or ones adopted from STUN, would most probably make most sense. But > there may be other aspects beyond the size and complexity of the code. > > Any implementors around, your opinions? I already gave a comment on the fragmentation to reduce extra RTTs. >> 4) Do we follow ICE procedures exactly, or do we do some variations if they >> seem appropriate? >> (Hannes and Dan are proposing to follow the ICE procedures almost >> exactly; >> Miika is proposing a protocol that is ICE-like) > > This one goes beyond my current understanding. I believe I borrowed all ideas from ICE that HIP needs. I am open for more detailed comments if someone finds any. >> 6) How do we handle mobility? >> (Since this is something not really handled by ICE today) > > Mobility is pretty much handled by the M&M draft, though perhaps not fully > for make-before-break or multi-homing situations. But, are there any good > reasons to deviate from that draft? If there are, I'd like to here them > explicitly. That draft has been around, in various forms, for three or four > years and has received quite a lot of scrutiny. draft-ietf-hip-nat-traversal-02-pre6 is heavily based on draft-hip-mm. >> 7) Do two HIP endpoints ALWAYS perform ICE, even if they have reasons to >> believe >> that they both have public addresses? >> (With SIP, the proposal is to always run ICE, partly because there is no >> sure >> way for an endpoint to tell when ICE is not needed, and partly because >> ICE >> brings advantages beyond NAT traversal: for example, selection of the >> best address >> to use when an endpoint is multihomed). > > Something similar we have discussed several times in the past. > > My strong opinion has been that from an architectural point of view it would > make most sense to try to run HIP directly, without UDP encapsulation, first. > Or at least in parallel with the UDP-encapsulated exchange, in the case there > are strong reasons to suspect that UDP-encapsulation is needed. The main > rationality here is that from an architectural point of view UDP > encapsulation should eventually disappear (maybe in 20 years or so), and we > should *primarily* engineer our protocols for architectural cleanliness and > flexibility, and only secondarily for optimality under current circumstances. This is handled by the prioritization algorithm. It prioritizes non-UDP encapsulated reachability tests as the first. > In the past, idea in the HIP community has been to utilise the SHIM6 path > diversity protocol to select the best address(es). But maybe ICE is better > thought out, at least for the IPv4 NAT case. > > Anyway, as I said, perhaps the best way would be to draw the best ideas from > both ICE and SHIM6, and try to combine them for a HIP-specific mobility, path > diversity / multi-homing, and NAT traversal protocol. I think the M&M draft > takes care of most of the mobility-specific stuff already, offers some > initial hooks for multi-homing, and includes the LOCATOR parameter that was > explicitly designed to allow NAT traversal. Agree. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 08:00:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nFV-0005ur-3N; Mon, 25 Jun 2007 08:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nFQ-0005uV-FQ for hipsec@ietf.org; Mon, 25 Jun 2007 08:00:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2nFP-00072i-2r for hipsec@ietf.org; Mon, 25 Jun 2007 08:00:48 -0400 Received: (qmail invoked by alias); 25 Jun 2007 12:00:46 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp047) with SMTP; 25 Jun 2007 14:00:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ZE2sppUMZbw//4VH/pypqJmMBLIX0kXNoe23846 C9rdMPGk38WmLU Message-ID: <467FAE6D.1070807@gmx.net> Date: Mon, 25 Jun 2007 14:00:45 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: 'HIP WG' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Hipsec] Rebuilding ICE X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org I am really concerned about the current HIP NAT traversal work since one of the authors tries to re-build the ICE specification step-by-step without noticing that one could easily make us of it. I agree that you can turn any protocol in any other one if you just work hard enough. It took more than a years to figure out that there is something like ICE. How long will it take to copy it? _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 08:01:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nFx-00066Q-Ut; Mon, 25 Jun 2007 08:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nFx-00064z-2B for hipsec@lists.ietf.org; Mon, 25 Jun 2007 08:01:21 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2nFv-00076i-HM for hipsec@lists.ietf.org; Mon, 25 Jun 2007 08:01:21 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1F8612CE5; Mon, 25 Jun 2007 15:01:19 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 3FE9A2CD8; Mon, 25 Jun 2007 15:01:17 +0300 (EEST) Date: Mon, 25 Jun 2007 15:01:17 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Hannes Tschofenig Subject: Re: [Hipsec] Re: draft-tschofenig-hip-ice-00.txt In-Reply-To: <467FABEC.4010801@gmx.net> Message-ID: References: <02b301c7b50a$32cb6780$78a36b80@amer.cisco.com> <467FABEC.4010801@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 25 Jun 2007, Hannes Tschofenig wrote: Hannes, I did not understand your comment. The draft talks about rendezvous servers and even illustrates it in the Figure 1. Are you using STUN to relay HIP control packets? There were actually six questions in my email, each one separated into a bullet point. Please answer to each of them separately. > Hi Miika, > > as with NAT traversal in SIP the traversal over RVS and the registration at > the RVS is not subject to the draft. That's a different problem. > > Ciao > Hannes > > Miika Komu wrote: >> On Fri, 22 Jun 2007, Dan Wing wrote: >> >> Hi, >> >> seems like the discussion exploded during weekend. Answering to rest of the >> emails after this, but first few overall comments on the draft: >> >> The draft is missing flow graphs which makes it immensily difficult to >> understand how the protocol actually works. Particularly, I am interested >> in seeing all of the following things in flow diagrams: >> >> * Registration to RVS >> * Relaying of the base exchange through the RVS >> * Reachability detection >> * Handover with reachability detection >> >> After you have unblurred this information to the draft, we can compare the >> RTT between the drafts, which I think is generally larger in >> draft-tschofenig-hip-ice. >> >> I did not understand the state requirements for the RVS after a quick read: >> >> * Does the RVS forward all HIP control packets? >> * Does the RVS impose state towards the Initiator (aka "L") >> >> For draft-ietf-hip-nat-traversal-02-pre6, the answer to the first question >> is "yes" to provide 100 % reliability over legacy NATs. The answer to the >> second question is "no" to avoid DoSing or overloading the RVS server. >> >>> This document explains how we see ICE and HIP could work together. >>> Comments >>> welcome. >>> >>> -d >>> >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> >>>> Title : Utilizing Interactive Connectivity >>>> Establishment (ICE) for the Host Identity Protocol (HIP) >>>> Author(s) : H. Tschofenig, D. Wing >>>> Filename : draft-tschofenig-hip-ice-00.txt >>>> Pages : 22 >>>> Date : 2007-6-22 >>>> >>>> >>>> This document describes how the Interactive Connectivity >>>> Establishment (ICE) methodology can be used for the Host Identity >>>> Protocol (HIP) to determine whether end-to-end communication is >>>> possible. ICE makes use of the Session Traversal Utilities for NAT >>>> (STUN) protocol in addition to mechanisms for checking connectivity >>>> between peers. After running the ICE the two HIP end >>>> points will be >>>> able to communicate directly or through a relay via Network Address >>>> Translators (NATs), Network Address and Port Translators >>>> (NAPTs) and >>>> firewalls . >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-tschofenig-hip-ice-00.txt >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in >>>> the body of >>>> the message. >>>> You can also visit >>>> https://www1.ietf.org/mailman/listinfo/I-D-announce >>>> to change your subscription settings. >>>> >>>> Internet-Drafts are also available by anonymous FTP. Login with the >>>> username "anonymous" and a password of your e-mail address. After >>>> logging in, type "cd internet-drafts" and then >>>> "get draft-tschofenig-hip-ice-00.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE /internet-drafts/draft-tschofenig-hip-ice-00.txt". >>>> >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need "munpack" or >>>> a MIME-compliant mail reader. Different MIME-compliant >>>> mail readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have been split >>>> up into multiple messages), so check your local documentation on >>>> how to manipulate these messages. >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>> >> > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 08:11:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nPO-0005Cp-Ei; Mon, 25 Jun 2007 08:11:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nPN-0005CY-4w for hipsec@ietf.org; Mon, 25 Jun 2007 08:11:05 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I2nPK-0002IX-Oe for hipsec@ietf.org; Mon, 25 Jun 2007 08:11:05 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5402B2D23; Mon, 25 Jun 2007 15:11:01 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id CF1012CEE; Mon, 25 Jun 2007 15:11:00 +0300 (EEST) Date: Mon, 25 Jun 2007 15:11:00 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Hannes Tschofenig Subject: Re: [Hipsec] Re: ICE-for-HIP design choice: STUN or HIP? In-Reply-To: <467FAC44.8050502@gmx.net> Message-ID: References: <498F4BCB-9FD7-4F0D-813A-289C6D9C0656@magma.ca> <467FAC44.8050502@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: HIP WG , Hannes Tschofenig , Philip Matthews X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 25 Jun 2007, Hannes Tschofenig wrote: > What do you mean by "The use of a HIP-aware middlebox in reliable legacy NAT > traversal is mandatory."? There must be a middlebox that relays HIP control packets when the Responder or both peers are behind NATs. The relay is also very important when there are p2p-unfriendly NATs on the path. > A HIP aware middlebox is a NAT or a firewall that understands HIP. None of > the drafts in the HIP working group address that topic. draft-ietf-hip-nat-traversal-02-pre6 includes a HIP-relay for forwarding UDP-encapsulated HIP control packets. Btw, I don't understand why the rendezvous servers need to talk each other as described in Figure 1 of draft-tschofenig-hip-ice-00 ? At least in the hip-rvs specification (and also nat-02-pre06), the Initiator contacts directly the RVS of the Responder. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 08:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nTZ-0007Ra-5F; Mon, 25 Jun 2007 08:15:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2nTX-0007RP-UO for hipsec@ietf.org; Mon, 25 Jun 2007 08:15:23 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2nTW-0001UI-KM for hipsec@ietf.org; Mon, 25 Jun 2007 08:15:23 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A8F492D61; Mon, 25 Jun 2007 15:15:17 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 047632D23; Mon, 25 Jun 2007 15:15:17 +0300 (EEST) Date: Mon, 25 Jun 2007 15:15:16 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Hannes Tschofenig Subject: Re: [Hipsec] RE: ICE-for-HIP design choice: STUN or HIP? In-Reply-To: <467FACAB.9070903@gmx.net> Message-ID: References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> <467FACAB.9070903@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'HIP WG' , 'Hannes Tschofenig' , 'Philip Matthews' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 25 Jun 2007, Hannes Tschofenig wrote: > Hi Miika > > Miika Komu wrote: >> On Sat, 23 Jun 2007, Dan Wing wrote: >> >>> The important difference with draft-tschofenig-hip-ice isn't the >>> encoding on-the-wire. >> >> Disagree. I think the debate is exactly about the format on the wire, see >> below. >> > The encoding of the candidates that are exchanged is not really so important. > The concept is important and to make use of work that was done elsewhere is > (rather than reinventing the wheel). Hi Hannes, just to clarify, draft-ietf-hip-nat-traversal-02-pre6 does reinvent any wheel but rather is based on ICE concepts, similarly as draft-tschofenig-hip-ice-00. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 12:25:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rNU-0007jI-Ax; Mon, 25 Jun 2007 12:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rNS-0007jB-9g for hipsec@ietf.org; Mon, 25 Jun 2007 12:25:22 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2rNQ-0004zH-Uo for hipsec@ietf.org; Mon, 25 Jun 2007 12:25:22 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B54B2212DDE; Mon, 25 Jun 2007 19:25:19 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 53B34212D1A; Mon, 25 Jun 2007 19:25:19 +0300 (EEST) In-Reply-To: <467FAE6D.1070807@gmx.net> References: <467FAE6D.1070807@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D71D216-4C4B-4D2D-B581-D3CF079FB480@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Rebuilding ICE Date: Mon, 25 Jun 2007 19:25:17 +0300 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Just for the record: Firstly, I would be very worried about blindly adopting ICE for HIP as it. I don't see them as an architecturally nice fit. They have grown from different starting points, and that shows. Secondly, someone from the "ICE camp" claimed that the wire formats don't matter. If they indeed don't, what's wrong with adopting the ICE semantics but using HIP wire formats? --Pekka Nikander On 25 Jun 2007, at 15:00, Hannes Tschofenig wrote: > I am really concerned about the current HIP NAT traversal work > since one of the authors tries to re-build the ICE specification > step-by-step without noticing that one could easily make us of it. > > I agree that you can turn any protocol in any other one if you just > work hard enough. It took more than a years to figure out that > there is something like ICE. How long will it take to copy it? > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 12:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rsx-00062e-S7; Mon, 25 Jun 2007 12:57:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rsw-000610-6H for hipsec@ietf.org; Mon, 25 Jun 2007 12:57:54 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2rsu-0005Aw-TF for hipsec@ietf.org; Mon, 25 Jun 2007 12:57:54 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Jun 2007 09:57:52 -0700 X-IronPort-AV: i="4.16,460,1175497200"; d="scan'208"; a="171666720:sNHT43287507" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5PGvqOd020502; Mon, 25 Jun 2007 09:57:52 -0700 Received: from dwingwxp (sjc-vpn6-84.cisco.com [10.21.120.84]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5PGvgXH008328; Mon, 25 Jun 2007 16:57:42 GMT From: "Dan Wing" To: "'Miika Komu'" , "'Hannes Tschofenig'" Date: Mon, 25 Jun 2007 09:57:41 -0700 Message-ID: <041401c7b749$f7d49bf0$2e71150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace3HzaGEH6ESViiS2KHyWthXfzkKwAKhMfw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1312; t=1182790672; x=1183654672; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20ICE-for-HIP=3A=20the=20design=20choices |Sender:=20; bh=yp0dDOSgI84r/d3DrEP/FPIwxuG7hQ5O1J/ZordJi50=; b=gEsHab79nXsX+jQTpX08lLwyQBAeztXmz1v6yV8dLnLQsCYi3G4suFOqFN8W0Bl7+Zw7/GTV v1UkRfUg/Gh1zLGtDHlz22Z4zRfT9v1oQ2Oj+NE18DzbjiCsDnm1V59oMFp7Av22xHb1ufpsm5 2EjID9hxeCCDxJrBuLSdM4iiw=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'HIP WG' , 'Hannes Tschofenig' , 'Philip Matthews' Subject: [Hipsec] RE: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > > Well, there is ICE lite. We suggest to make use of it if > > one of the end point > > knows for sure that it has global IP addresses and is not > > located behind a > > stateful packet filtering firewall or similar stuff. > > This is addressed in draft-ietf-hip-nat-traversal-02-pre6: > > 3.4. Connectivity Tests > > There is no relay when the RELAY_TO parameters are not > present. In > this case, the hosts SHOULD allow the transmission of ESP traffic > even though the base exchange is sent over the transport layer. A > possible scenario where this can occur is when the Initiator is > behind a NAT and Responder is located in a public network. The hosts should only send traffic after a successful connectivity check. Otherwise if that NAT doesn't do what is commonly called "IPsec passthru" (which is NATting using the IPsec SPI), ESP won't work. And even in cases where IPsec Passthru is supported by a NAT, many of them are quite brain-dead in their support; for example, an old Linksys NAT that I own only allows one host behind the NAT to connect to one IPsec host -- if I try to have another host connect to the same VPN concentrator, that second host will never succeed (until I switch to IPsec-over-UDP or IPsec-over-TCP). -d _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 13:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s1B-0002iX-6M; Mon, 25 Jun 2007 13:06:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s19-0002iS-R3 for hipsec@ietf.org; Mon, 25 Jun 2007 13:06:23 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2s18-0008MX-KB for hipsec@ietf.org; Mon, 25 Jun 2007 13:06:23 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I2s17-0005e6-2C; Mon, 25 Jun 2007 13:06:21 -0400 In-Reply-To: References: <04c601c7b5bc$5d289bd0$78a36b80@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 25 Jun 2007 13:06:27 -0400 To: Miika Komu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'HIP WG' , 'Hannes Tschofenig' Subject: [Hipsec] Re: ICE-for-HIP design choice: STUN or HIP? X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 25-Jun-07, at 07:47 , Miika Komu wrote: > On Sat, 23 Jun 2007, Dan Wing wrote: > >> The important difference with draft-tschofenig-hip-ice isn't the >> encoding on-the-wire. > > Disagree. I think the debate is exactly about the format on the > wire, see below. I think it is partly about the format on the wire, but partly about other things, such as which packets to do the Offer/Answer exchange, what security mechanism to use, and how we handle mobility. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 13:11:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s6A-0004G6-Mk; Mon, 25 Jun 2007 13:11:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2s69-0004Fq-SZ for hipsec@ietf.org; Mon, 25 Jun 2007 13:11:33 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2s68-0000RD-L9 for hipsec@ietf.org; Mon, 25 Jun 2007 13:11:33 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I2s68-0007yn-0o; Mon, 25 Jun 2007 13:11:32 -0400 In-Reply-To: References: <498F4BCB-9FD7-4F0D-813A-289C6D9C0656@magma.ca> <467FAC44.8050502@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3881D6C6-AEB8-4D31-8B26-EA15A378FAEA@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Re: ICE-for-HIP design choice: STUN or HIP? Date: Mon, 25 Jun 2007 13:11:38 -0400 To: Miika Komu , Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: HIP WG , Hannes Tschofenig X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 25-Jun-07, at 08:11 , Miika Komu wrote: > On Mon, 25 Jun 2007, Hannes Tschofenig wrote: > >> What do you mean by "The use of a HIP-aware middlebox in reliable >> legacy NAT traversal is mandatory."? I think Miika is using the term "middlebox" to mean any device that operates above the IP layer along the path from the Initiator to the Responder. This includes NATs, RVSs, etc. I think that Hannes is using the term "middlebox" to refer to just NATs and Firewalls. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 14:15:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2t5t-0005Y9-3f; Mon, 25 Jun 2007 14:15:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2t5r-0005Y3-V9 for hipsec@ietf.org; Mon, 25 Jun 2007 14:15:19 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2t5p-0002Zg-KA for hipsec@ietf.org; Mon, 25 Jun 2007 14:15:19 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D7E432D76; Mon, 25 Jun 2007 21:15:16 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 57A5B2D76; Mon, 25 Jun 2007 21:15:16 +0300 (EEST) Date: Mon, 25 Jun 2007 21:15:16 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing In-Reply-To: <041401c7b749$f7d49bf0$2e71150a@amer.cisco.com> Message-ID: References: <041401c7b749$f7d49bf0$2e71150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'HIP WG' , 'Hannes Tschofenig' , 'Hannes Tschofenig' , 'Philip Matthews' Subject: [Hipsec] RE: ICE-for-HIP: the design choices X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 25 Jun 2007, Dan Wing wrote: > >>> Well, there is ICE lite. We suggest to make use of it if >>> one of the end point >>> knows for sure that it has global IP addresses and is not >>> located behind a >>> stateful packet filtering firewall or similar stuff. >> >> This is addressed in draft-ietf-hip-nat-traversal-02-pre6: >> >> 3.4. Connectivity Tests >> >> There is no relay when the RELAY_TO parameters are not >> present. In >> this case, the hosts SHOULD allow the transmission of ESP traffic >> even though the base exchange is sent over the transport layer. A >> possible scenario where this can occur is when the Initiator is >> behind a NAT and Responder is located in a public network. > > The hosts should only send traffic after a successful connectivity > check. Otherwise if that NAT doesn't do what is commonly called "IPsec > passthru" (which is NATting using the IPsec SPI), ESP won't work. And > even in cases where IPsec Passthru is supported by a NAT, many of them > are quite brain-dead in their support; for example, an old Linksys NAT > that I own only allows one host behind the NAT to connect to one IPsec > host -- if I try to have another host connect to the same VPN > concentrator, that second host will never succeed (until I switch > to IPsec-over-UDP or IPsec-over-TCP). The text I cited concerns only UDP-encapsulated ESP traffic. Perhaps I should clarify it to the draft. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 15:21:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2u81-00032j-Ad; Mon, 25 Jun 2007 15:21:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2u80-00032e-L5 for hipsec@ietf.org; Mon, 25 Jun 2007 15:21:36 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2u7z-0004rn-6Z for hipsec@ietf.org; Mon, 25 Jun 2007 15:21:36 -0400 Received: (qmail invoked by alias); 25 Jun 2007 19:21:33 -0000 Received: from p549860B5.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.96.181] by mail.gmx.net (mp018) with SMTP; 25 Jun 2007 21:21:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/TSHwFgFLTrCensRPMNFO+hS9wD0tJDy/Yx/+ZS2 oJH/EallZ6RzPZ Message-ID: <468015BC.3040601@gmx.net> Date: Mon, 25 Jun 2007 21:21:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Rebuilding ICE References: <467FAE6D.1070807@gmx.net> <4D71D216-4C4B-4D2D-B581-D3CF079FB480@nomadiclab.com> In-Reply-To: <4D71D216-4C4B-4D2D-B581-D3CF079FB480@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Also for the record: I have no clue why everyone is totally focused on the wire format. The ICE document has 100+ pages http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt and the most important considerations are not about the wire format. Ciao Hannes Pekka Nikander wrote: > Just for the record: > > Firstly, I would be very worried about blindly adopting ICE for HIP > as it. I don't see them as an architecturally nice fit. They have > grown from different starting points, and that shows. > > Secondly, someone from the "ICE camp" claimed that the wire formats > don't matter. If they indeed don't, what's wrong with adopting the > ICE semantics but using HIP wire formats? > > --Pekka Nikander > > On 25 Jun 2007, at 15:00, Hannes Tschofenig wrote: > >> I am really concerned about the current HIP NAT traversal work since >> one of the authors tries to re-build the ICE specification >> step-by-step without noticing that one could easily make us of it. >> >> I agree that you can turn any protocol in any other one if you just >> work hard enough. It took more than a years to figure out that there >> is something like ICE. How long will it take to copy it? >> >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 15:45:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uVV-0003nk-U8; Mon, 25 Jun 2007 15:45:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2uVU-0003mU-HZ for hipsec@ietf.org; Mon, 25 Jun 2007 15:45:52 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2uVT-0003UA-1v for hipsec@ietf.org; Mon, 25 Jun 2007 15:45:52 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C28A6212DDE; Mon, 25 Jun 2007 22:45:49 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 64BDF212D1A; Mon, 25 Jun 2007 22:45:49 +0300 (EEST) In-Reply-To: <468015BC.3040601@gmx.net> References: <467FAE6D.1070807@gmx.net> <4D71D216-4C4B-4D2D-B581-D3CF079FB480@nomadiclab.com> <468015BC.3040601@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Rebuilding ICE Date: Mon, 25 Jun 2007 22:45:44 +0300 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hannes, First, I may be completely wrong here since I haven't had time to read any of the in question drafts and most probably won't have that time, either. However, as far as I've understood, what Miika et al have done is pretty straightforward adoption of ICE, with the exception of the wire formats. Hence, my (perhaps very flawed) understanding of their draft is that they are relying on the ICE spec, basically adopting it to the HIP environment by re-using the mechanisms and semantics and re-defining new wire formats and messages. But maybe I'm wrong. I'm sure Miika can clarify. Personally, I don't see how a protocol changes if the protocol machine is kept the same and there are semantically equivalent messages and parameters. At least the formal model of the protocol nor the formal characteristics don't change from such re-labeling of the messages and parameters. Yes, sure, its interactions with the environment may changes, but as I have already explained, my understanding of the goal here is to make HIP to work with legacy NATs. HIP-aware NATs are then a different story -- they have already been implemented; you are yourself a co-author of the SecureComm SPINAT paper. Why I'm giving my opinions here is that I'm (perhaps surprisingly) still interested about the sanity and cleanliness of HIP, in terms of implementation and architecture. I don't want it to be *unnecessarily* messed with non-suitable wire formats or additional, avoidable messages. However, if there are clear, quantifiable *reasons* why doing the thing differently that what Miika et al have done so far, sure, we need to learn that. And adopt accordingly. I've tried to explain my reasons, as clearly as I can. I haven't seen much *well-founded* reasoning yet from you, but maybe I'm just blind and doesn't see it at the front of my eyes. --Pekka On 25 Jun 2007, at 22:21, Hannes Tschofenig wrote: > Also for the record: > > I have no clue why everyone is totally focused on the wire format. > > The ICE document has 100+ pages > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt > and the most important considerations are not about the wire format. > > Ciao > Hannes > > Pekka Nikander wrote: >> Just for the record: >> >> Firstly, I would be very worried about blindly adopting ICE for >> HIP as it. I don't see them as an architecturally nice fit. They >> have grown from different starting points, and that shows. >> >> Secondly, someone from the "ICE camp" claimed that the wire >> formats don't matter. If they indeed don't, what's wrong with >> adopting the ICE semantics but using HIP wire formats? >> >> --Pekka Nikander >> >> On 25 Jun 2007, at 15:00, Hannes Tschofenig wrote: >> >>> I am really concerned about the current HIP NAT traversal work >>> since one of the authors tries to re-build the ICE specification >>> step-by-step without noticing that one could easily make us of it. >>> >>> I agree that you can turn any protocol in any other one if you >>> just work hard enough. It took more than a years to figure out >>> that there is something like ICE. How long will it take to copy it? >>> >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >>> > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 25 17:05:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2vk7-0003YJ-7U; Mon, 25 Jun 2007 17:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2vk6-0003YC-4n for hipsec@ietf.org; Mon, 25 Jun 2007 17:05:02 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2vk4-0006lg-RN for hipsec@ietf.org; Mon, 25 Jun 2007 17:05:02 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 14B062D65; Tue, 26 Jun 2007 00:05:00 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 8E05B2D12; Tue, 26 Jun 2007 00:04:59 +0300 (EEST) Date: Tue, 26 Jun 2007 00:04:59 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [Hipsec] Rebuilding ICE In-Reply-To: Message-ID: References: <467FAE6D.1070807@gmx.net> <4D71D216-4C4B-4D2D-B581-D3CF079FB480@nomadiclab.com> <468015BC.3040601@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: HIP WG , Hannes Tschofenig X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 25 Jun 2007, Pekka Nikander wrote: > Hannes, > > First, I may be completely wrong here since I haven't had time to read any of > the in question drafts and most probably won't have that time, either. > However, as far as I've understood, what Miika et al have done is pretty > straightforward adoption of ICE, with the exception of the wire formats. > Hence, my (perhaps very flawed) understanding of their draft is that they are > relying on the ICE spec, basically adopting it to the HIP environment by > re-using the mechanisms and semantics and re-defining new wire formats and > messages. > > But maybe I'm wrong. I'm sure Miika can clarify. You are correct. I'd be happy to discuss if there is something essential still missing from the draft. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 02:52:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I34uI-00064J-A9; Tue, 26 Jun 2007 02:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2tkq-0007n1-EM for hipsec@ietf.org; Mon, 25 Jun 2007 14:57:40 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2tkp-0004oF-24 for hipsec@ietf.org; Mon, 25 Jun 2007 14:57:40 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8157420102C6; Mon, 25 Jun 2007 20:57:38 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJFmByDNdte1; Mon, 25 Jun 2007 20:57:38 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6D9FB200017E; Mon, 25 Jun 2007 20:57:28 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Rebuilding ICE Date: Mon, 25 Jun 2007 20:58:30 +0200 Message-ID: In-Reply-To: <467FAE6D.1070807@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Rebuilding ICE Thread-Index: Ace3IKxsWg5TGNa5R0mMq3NsRjBs7gAE8Zdg References: <467FAE6D.1070807@gmx.net> From: "Marcus Brunner" To: "Hannes Tschofenig" , "HIP WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Tue, 26 Jun 2007 02:52:08 -0400 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Sorry, but I don't get where the problem really is. Looks both = approaches are sort of an ICE adaptation to HIP (I assume Hannes not = proposing the ICE for SDP encoding for HIP or?). If this is true, the details of both approaches must be on the table. = Then we can discuss.=20 Kind regards, Marcus --------------------------------------------------- Dr. Marcus Brunner NEC Laboratories Europe Network Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Monday, June 25, 2007 2:01 PM > To: 'HIP WG' > Subject: [Hipsec] Rebuilding ICE >=20 > I am really concerned about the current HIP NAT traversal=20 > work since one of the authors tries to re-build the ICE=20 > specification step-by-step without noticing that one could=20 > easily make us of it. >=20 > I agree that you can turn any protocol in any other one if=20 > you just work hard enough. It took more than a years to=20 > figure out that there is something like ICE. How long will it=20 > take to copy it? >=20 >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 03:41:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35g3-0002LC-89; Tue, 26 Jun 2007 03:41:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35g1-0002Ji-QO for hipsec@ietf.org; Tue, 26 Jun 2007 03:41:29 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I35fx-0003H7-58 for hipsec@ietf.org; Tue, 26 Jun 2007 03:41:29 -0400 Received: (qmail invoked by alias); 26 Jun 2007 07:41:24 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp002) with SMTP; 26 Jun 2007 09:41:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/wXwMiU5DwVwczG7b20a1jS27cptSfHuxfYxIbxK PXIrygSvUUrMzh Message-ID: <4680C323.2030709@gmx.net> Date: Tue, 26 Jun 2007 09:41:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Marcus Brunner Subject: Re: [Hipsec] Rebuilding ICE References: <467FAE6D.1070807@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Marcus, Thanks to Phillip Matthews and Dan Wing who actually pointed the group to ICE. Without them there would not be a single line in the current WG NAT traversal draft. Instead of being thankful that the group receives input from other groups in the IETF a few individuals switched to the panic mode. Hello? In the IETF it is quite common to receive input from people that have a different background. Ciao Hannes > -----Ursprüngliche Nachricht----- > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de] > Gesendet: Montag, 25. Juni 2007 20:59 > An: Hannes Tschofenig; HIP WG > Betreff: RE: [Hipsec] Rebuilding ICE > > Sorry, but I don't get where the problem really is. Looks > both approaches are sort of an ICE adaptation to HIP (I > assume Hannes not proposing the ICE for SDP encoding for HIP or?). > > If this is true, the details of both approaches must be on > the table. Then we can discuss. > > > Kind regards, > > Marcus > > --------------------------------------------------- > > Dr. Marcus Brunner > NEC Laboratories Europe > Network Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > Road, London W3 6BL | Registered in England 2832014 > > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Monday, June 25, 2007 2:01 PM > > To: 'HIP WG' > > Subject: [Hipsec] Rebuilding ICE > > > > I am really concerned about the current HIP NAT traversal > > work since one of the authors tries to re-build the ICE > > specification step-by-step without noticing that one could > > easily make us of it. > > > > I agree that you can turn any protocol in any other one if > > you just work hard enough. It took more than a years to > > figure out that there is something like ICE. How long will it > > take to copy it? > > > > > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 03:46:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35lH-0005kX-4b; Tue, 26 Jun 2007 03:46:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35lF-0005kO-Hd for hipsec@ietf.org; Tue, 26 Jun 2007 03:46:53 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35lA-0004dq-O1 for hipsec@ietf.org; Tue, 26 Jun 2007 03:46:53 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id TAA11161; Tue, 26 Jun 2007 19:46:38 +1200 In-Reply-To: <4680C323.2030709@gmx.net> References: <467FAE6D.1070807@gmx.net> <4680C323.2030709@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> Content-Transfer-Encoding: quoted-printable From: Andrew McGregor Subject: Re: [Hipsec] Rebuilding ICE Date: Tue, 26 Jun 2007 19:47:01 +1200 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: HIP WG , Marcus Brunner X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hannes, there was quite a long conversation in Prague about the =20 relationship between ICE and HIP, and IIRC that's where the approach =20 of taking ICE mechanism into HIP packet formats came from. I think =20 the approach is valid, as the ICE formats were evolved in a =20 completely different context. It's also fairly clear that there is =20 reason to somewhat adapt ICE anyway; it does provide us with a very =20 well researched set of mechanisms for traversing NATs, but it also =20 brings along some SIP-specific baggage that could be removed without =20 harming the NAT traversal. Andrew On 26/06/2007, at 7:41 PM, Hannes Tschofenig wrote: > Hi Marcus, > > Thanks to Phillip Matthews and Dan Wing who actually pointed the =20 > group to ICE. Without them there would not be a single line in the =20 > current WG NAT traversal draft. > > Instead of being thankful that the group receives input from other =20 > groups in the IETF a few individuals switched to the panic mode. > > Hello? > > In the IETF it is quite common to receive input from people that =20 > have a different background. > > Ciao > Hannes > > > -----Urspr=FCngliche Nachricht----- > > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de] > > Gesendet: Montag, 25. Juni 2007 20:59 > > An: Hannes Tschofenig; HIP WG > > Betreff: RE: [Hipsec] Rebuilding ICE > > > > Sorry, but I don't get where the problem really is. Looks > > both approaches are sort of an ICE adaptation to HIP (I > > assume Hannes not proposing the ICE for SDP encoding for HIP or?). > > > > If this is true, the details of both approaches must be on > > the table. Then we can discuss. > > > > > > Kind regards, > > > > Marcus > > > > --------------------------------------------------- > > > > Dr. Marcus Brunner > > NEC Laboratories Europe > > Network Division > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > Road, London W3 6BL | Registered in England 2832014 > > > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Monday, June 25, 2007 2:01 PM > > > To: 'HIP WG' > > > Subject: [Hipsec] Rebuilding ICE > > > > > > I am really concerned about the current HIP NAT traversal > > > work since one of the authors tries to re-build the ICE > > > specification step-by-step without noticing that one could > > > easily make us of it. > > > > > > I agree that you can turn any protocol in any other one if > > > you just work hard enough. It took more than a years to > > > figure out that there is something like ICE. How long will it > > > take to copy it? > > > > > > > > > > > > _______________________________________________ > > > Hipsec mailing list > > > Hipsec@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/hipsec > > > > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 03:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35wP-0006Lk-V5; Tue, 26 Jun 2007 03:58:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35wO-0006Lb-1r for hipsec@ietf.org; Tue, 26 Jun 2007 03:58:24 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35wA-0000aV-4X for hipsec@ietf.org; Tue, 26 Jun 2007 03:58:24 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8DCFD13CF81; Tue, 26 Jun 2007 09:58:09 +0200 (CEST) In-Reply-To: <69DA200E-6FBA-4965-928E-5FD4D585F79E@magma.ca> References: <69DA200E-6FBA-4965-928E-5FD4D585F79E@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Martin Stiemerling Subject: Re: [Hipsec] I-D on using HIP for P2PSIP: Date: Tue, 26 Jun 2007 09:58:08 +0200 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: HIP WG , Alan Johnston , Eric Cooper , hipsec-rg@listserv.cybertrust.com X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0456720125==" Errors-To: hipsec-bounces@lists.ietf.org --===============0456720125== Content-Type: multipart/alternative; boundary=Apple-Mail-6-526542140 --Apple-Mail-6-526542140 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Philip, Just to let you know: We have a P2PSIP prototype already using HIP for building and running the overlay. Martin Am 18.06.2007 um 21:49 schrieb Philip Matthews: > Folks: > > I would like to call your attention to a draft that was just > submitted to the P2PSIP working group. > This document proposes to use HIP as the basis in forming a P2PSIP > overlay network. > > The draft is a high-level draft that is trying to sell the P2PSIP > group on the idea of using HIP, rather than a detailed design. So we > simply sketch the ideas in a broad fashion, rather than giving > precise details. However, the authors still feel the draft will > likely be of interest to the HIP community. > > In particular, what is likely of greatest interest are the four HIP > extensions that the draft proposes: > * Defining how to route HIP packets though intermediate peers in an > overlay; > * Adding a new HIP packet type (which we call the Data packet) to > transport upper-layer protocols > in the overlay when the transmission path goes through one or > more intermediate peers; > * Extending the procedures for establishing a HIP association to the > case where a peer wants to join an overlay; > * Proposing alternative transport stack for protocols where running > over ESP is undesirable (e.g. Secure RTP transport of voice packets). > > The authors would be very interested in getting feedback from the HIP > community on these proposed extensions. > > From a HIP prospective, what is interesting is that this approach > provides a motivation for people to use HIP, because it is using HIP > in a "closed" system: a peer-to-peer overlay. > > The document was just submitted on the weekend, and had not yet > appeared in archives when this was written. > Until it does, you can get a copy at: > http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- > hop-00.txt > or an HTML version at: > http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- > hop-00.htm > > - Philip > > [I am cross-posting this to the HIP RG list, but after discussion > with Gonzalo, we think that the HIP WG mailing list is the best place > to discuss the details of the proposed HIP extensions. However, if > you have any general comments on the suitability of HIP for P2PSIP, > or general comments on the draft, then those comments are best > directed to the P2PSIP list.] > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 --Apple-Mail-6-526542140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Philip,

Just to let you know: We = have a P2PSIP prototype already using HIP for building and running the = overlay.=A0

=A0Martin
=A0
Am 18.06.2007 um 21:49 schrieb Philip Matthews:

Folks:

I would like to call your = attention to a draft that was just =A0
This = document proposes to use HIP as the basis in forming a P2PSIP =A0
overlay = network.

The draft is a high-level draft that is trying to = sell the P2PSIP =A0
group on the idea of using HIP, rather than a = detailed design. So we =A0
simply = sketch the ideas in a broad fashion, rather than giving =A0
precise = details. However, the authors still feel the draft will =A0
likely = be of interest to the HIP community.

In particular, what is likely of = greatest interest are the four HIP =A0
*=A0 Defining how to route HIP = packets though intermediate peers in an =A0
*=A0 Adding a new HIP packet type = (which we call the Data packet) to =A0
=A0 =A0 in the overlay when the = transmission path goes through one or =A0
more = intermediate peers;
*=A0 Extending the procedures for = establishing a HIP association to the =A0
case = where a peer wants to join an overlay;
*=A0 Proposing alternative = transport stack for protocols where running =A0
over ESP = is undesirable (e.g. Secure RTP transport of voice packets).

The = authors would be very interested in getting feedback from the HIP =A0

=A0=46rom a HIP prospective, what = is interesting is that this approach =A0
provides = a motivation for people to use HIP, because it is using HIP =A0
in a = "closed" system: a peer-to-peer overlay.

The document = was just submitted on the weekend, and had not yet =A0
appeared = in archives when this was written.
Until it = does, you can get a copy at:
or an HTML version at:

- Philip

[I am cross-posting this to the = HIP RG list, but after discussion =A0
with = Gonzalo, we think that the HIP WG mailing list is the best place =A0
to = discuss the details of the proposed HIP extensions. However, if =A0
you have = any general comments on the suitability of HIP for P2PSIP, =A0
or = general comments on the draft, then those comments are best =A0
directed = to the P2PSIP list.]


Hipsec mailing list

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-6-526542140-- --===============0456720125== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0456720125==-- From hipsec-bounces@lists.ietf.org Tue Jun 26 04:12:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I369w-0001ES-Ti; Tue, 26 Jun 2007 04:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I369u-0001EG-DA for hipsec@ietf.org; Tue, 26 Jun 2007 04:12:22 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3697-00036w-RQ for hipsec@ietf.org; Tue, 26 Jun 2007 04:12:22 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5DFBB13CF81 for ; Tue, 26 Jun 2007 10:11:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> References: <467FAE6D.1070807@gmx.net> <4680C323.2030709@gmx.net> <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> Message-Id: <3D4C521F-8586-4B49-A32B-6BE8D42A18BF@netlab.nec.de> From: Martin Stiemerling Subject: Re: [Hipsec] Rebuilding ICE Date: Tue, 26 Jun 2007 10:11:31 +0200 To: HIP WG X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1436537734==" Errors-To: hipsec-bounces@lists.ietf.org --===============1436537734== Content-Type: multipart/alternative; boundary=Apple-Mail-7-527344971 --Apple-Mail-7-527344971 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi all, I think that the discussion slipped off the actually topic a bit. The =20= main questions are basically: 1. the current HIP NAT traversal draft (draft-ietf-hip-nat-traversal-01) 2. using ICE and HIP in one way or the other For 1: There is some disagreement between the authors of the draft on how to =20= continue with the draft as the WG approved approach (draft-ietf-hip-=20 nat-traversal-01) and the current approach in the upcoming draft are =20 fundamental different. We have asked the chairs about their opinion =20 on this but have not received any answer. IMHO I do not like the approach taken right now on rebuilding ICE and =20= something different. I do like much more the simple approach take in =20 draft-ietf-hip-nat-traversal-01 as we need to get a start on HIP's =20 NAT traversal. For 2: Using something as ICE (must not be directly ICE, i.e., subject to =20 further discussions) could be helpful for HIP's NAT traversal. BUT: =20 The WG has agreed on the approach in draft-ietf-hip-nat-traversal-01 =20 and not on something different. Furthermore, I do think it is much =20 more worth on completing existing work and to bring it to the field =20 for further testing and studying (remember it is an experimental =20 draft only!). So, why not finishing things up first and going than for something =20 different? Thanks, Martin Am 26.06.2007 um 09:47 schrieb Andrew McGregor: > Hannes, there was quite a long conversation in Prague about the =20 > relationship between ICE and HIP, and IIRC that's where the =20 > approach of taking ICE mechanism into HIP packet formats came =20 > from. I think the approach is valid, as the ICE formats were =20 > evolved in a completely different context. It's also fairly clear =20 > that there is reason to somewhat adapt ICE anyway; it does provide =20 > us with a very well researched set of mechanisms for traversing =20 > NATs, but it also brings along some SIP-specific baggage that could =20= > be removed without harming the NAT traversal. > > Andrew > > On 26/06/2007, at 7:41 PM, Hannes Tschofenig wrote: > >> Hi Marcus, >> >> Thanks to Phillip Matthews and Dan Wing who actually pointed the =20 >> group to ICE. Without them there would not be a single line in the =20= >> current WG NAT traversal draft. >> >> Instead of being thankful that the group receives input from other =20= >> groups in the IETF a few individuals switched to the panic mode. >> >> Hello? >> >> In the IETF it is quite common to receive input from people that =20 >> have a different background. >> >> Ciao >> Hannes >> >> > -----Urspr=FCngliche Nachricht----- >> > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de] >> > Gesendet: Montag, 25. Juni 2007 20:59 >> > An: Hannes Tschofenig; HIP WG >> > Betreff: RE: [Hipsec] Rebuilding ICE >> > >> > Sorry, but I don't get where the problem really is. Looks >> > both approaches are sort of an ICE adaptation to HIP (I >> > assume Hannes not proposing the ICE for SDP encoding for HIP or?). >> > >> > If this is true, the details of both approaches must be on >> > the table. Then we can discuss. >> > >> > >> > Kind regards, >> > >> > Marcus >> > >> > --------------------------------------------------- >> > >> > Dr. Marcus Brunner >> > NEC Laboratories Europe >> > Network Division >> > >> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria >> > Road, London W3 6BL | Registered in England 2832014 >> > >> > > >> > > -----Original Message----- >> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> > > Sent: Monday, June 25, 2007 2:01 PM >> > > To: 'HIP WG' >> > > Subject: [Hipsec] Rebuilding ICE >> > > >> > > I am really concerned about the current HIP NAT traversal >> > > work since one of the authors tries to re-build the ICE >> > > specification step-by-step without noticing that one could >> > > easily make us of it. >> > > >> > > I agree that you can turn any protocol in any other one if >> > > you just work hard enough. It took more than a years to >> > > figure out that there is something like ICE. How long will it >> > > take to copy it? >> > > >> > > >> > > >> > > _______________________________________________ >> > > Hipsec mailing list >> > > Hipsec@lists.ietf.org >> > > https://www1.ietf.org/mailman/listinfo/hipsec >> > > >> > >> > _______________________________________________ >> > Hipsec mailing list >> > Hipsec@lists.ietf.org >> > https://www1.ietf.org/mailman/listinfo/hipsec >> > >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, =20 London W3 6BL | Registered in England 2832014 --Apple-Mail-7-527344971 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi all,

I think that the discussion = slipped off the actually topic a bit. The main questions are = basically:
1.=A0the current HIP NAT traversal draft = (draft-ietf-hip-nat-traversal-01)
2. using ICE and HIP in one = way or the other

For 1:
There is = some disagreement between the authors of the draft on how to continue = with the draft as the WG approved approach = (draft-ietf-hip-nat-traversal-01)=A0and the current approach in the = upcoming draft are fundamental different. We have asked the chairs about = their opinion on this but have not received any answer.
IMHO I = do not like the approach taken right now on rebuilding ICE and something = different. I do like much more the simple approach take = in=A0draft-ietf-hip-nat-traversal-01 as we need to get a start on HIP's = NAT traversal.

For 2:
Using = something as ICE (must not be directly ICE, i.e., subject to further = discussions) could be helpful for HIP's NAT traversal. BUT: The WG has = agreed on the approach in=A0draft-ietf-hip-nat-traversal-01=A0and not on = something different. Furthermore, I do think it is much more worth on = completing existing work and to bring it to the field for further = testing and studying (remember it is an experimental draft = only!).=A0
So, why not finishing things up first and going = than for something different?

Thanks,

=A0 = Martin

Am 26.06.2007 um 09:47 schrieb Andrew = McGregor:

Hannes, there was quite a long = conversation in Prague about the relationship between ICE and HIP, and = IIRC that's where the approach of taking ICE mechanism into HIP packet = formats came from.=A0 I = think the approach is valid, as the ICE formats were evolved in a = completely different context.=A0 = It's also fairly clear that there is reason to somewhat adapt ICE = anyway; it does provide us with a very well researched set of mechanisms = for traversing NATs, but it also brings along some SIP-specific baggage = that could be removed without harming the NAT traversal.


On 26/06/2007, at 7:41 PM, Hannes Tschofenig = wrote:

=
Hi Marcus,

Thanks = to Phillip Matthews and Dan Wing who actually pointed the group to ICE. = Without them there would not be a single line in the current WG NAT = traversal draft.

Instead of being thankful that the group receives = input from other groups in the IETF a few individuals switched to the = panic mode.

Hello?

In the IETF it is quite common = to receive input from people that have a different background.

Hannes

> = -----Urspr=FCngliche Nachricht-----
> Von: = Marcus Brunner [mailto:Brunner@netlab.nec.de]
> Gesendet: Montag, 25. Juni 2007 20:59
> An: Hannes Tschofenig; HIP WG
> Betreff: RE: [Hipsec] Rebuilding ICE
>
> Sorry, = but I don't get where the problem really is. Looks
> both approaches are sort of an ICE adaptation = to HIP (I
> assume Hannes not proposing = the ICE for SDP encoding for HIP or?).
> If this is true, the = details of both approaches must be on
> the = table. Then we can discuss.
>
> Kind regards,
> Marcus
>
> = ---------------------------------------------------
>
> Dr. = Marcus Brunner
> NEC Laboratories = Europe
> Network Division
>
> NEC = Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL | Registered in England = 2832014
>
>=A0 = >
> > -----Original = Message-----
> > From: Hannes = Tschofenig [mailto:Hannes.Tschofenig@gmx.net= ]
> > Sent: Monday, June 25, = 2007 2:01 PM
> > To: 'HIP WG'
> > Subject: [Hipsec] Rebuilding ICE
> >
> > I = am really concerned about the current HIP NAT traversal
> > work since one of the authors tries to = re-build the ICE
> > specification = step-by-step without noticing that one could
> > easily make us of it.
> >
> > I = agree that you can turn any protocol in any other one if
> > you just work hard enough. It took more = than a years to
> > figure out that there = is something like ICE. How long will it
> = > take to copy it?
> >
> >
> = >
> > = _______________________________________________
> > Hipsec mailing list
> = >
>
> = _______________________________________________
> Hipsec mailing list

Hipsec mailing list



Hipsec mailing list

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-7-527344971-- --===============1436537734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1436537734==-- From hipsec-bounces@lists.ietf.org Tue Jun 26 04:14:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I36Bq-0002Wo-9i; Tue, 26 Jun 2007 04:14:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I355z-0006OY-V3 for hipsec@ietf.org; Tue, 26 Jun 2007 03:04:16 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I355z-0007It-HB for hipsec@ietf.org; Tue, 26 Jun 2007 03:04:15 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l5Q73fZb010169; Tue, 26 Jun 2007 09:03:41 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l5Q73Zkb027453; Tue, 26 Jun 2007 09:03:41 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 09:03:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Hipsec] Rebuilding ICE Date: Tue, 26 Jun 2007 09:03:10 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC2F6@MCHP7IDA.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Rebuilding ICE Thread-Index: Ace3IKxsWg5TGNa5R0mMq3NsRjBs7gAE8ZdgACKZp5A= From: "Tschofenig, Hannes" To: "Marcus Brunner" , "Hannes Tschofenig" , "HIP WG" X-OriginalArrivalTime: 26 Jun 2007 07:03:37.0407 (UTC) FILETIME=[1E5884F0:01C7B7C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Tue, 26 Jun 2007 04:14:21 -0400 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Marcus,=20 Thanks to Phillip Matthews and Dan Wing who actually pointed the group = to ICE. Without them there would not be a single line in the current WG = NAT traversal draft.=20 Instead of being thankful that the group receives input from other = groups in the IETF a few individuals swiched to the panic mode. Hello?=20 In the IETF it is quite common to receive input from people that have a = different background. Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de]=20 > Gesendet: Montag, 25. Juni 2007 20:59 > An: Hannes Tschofenig; HIP WG > Betreff: RE: [Hipsec] Rebuilding ICE >=20 > Sorry, but I don't get where the problem really is. Looks=20 > both approaches are sort of an ICE adaptation to HIP (I=20 > assume Hannes not proposing the ICE for SDP encoding for HIP or?). >=20 > If this is true, the details of both approaches must be on=20 > the table. Then we can discuss.=20 >=20 >=20 > Kind regards, >=20 > Marcus >=20 > --------------------------------------------------- >=20 > Dr. Marcus Brunner > NEC Laboratories Europe > Network Division >=20 > NEC Europe Limited | Registered Office: NEC House, 1 Victoria=20 > Road, London W3 6BL | Registered in England 2832014 >=20 > =20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: Monday, June 25, 2007 2:01 PM > > To: 'HIP WG' > > Subject: [Hipsec] Rebuilding ICE > >=20 > > I am really concerned about the current HIP NAT traversal=20 > > work since one of the authors tries to re-build the ICE=20 > > specification step-by-step without noticing that one could=20 > > easily make us of it. > >=20 > > I agree that you can turn any protocol in any other one if=20 > > you just work hard enough. It took more than a years to=20 > > figure out that there is something like ICE. How long will it=20 > > take to copy it? > >=20 > >=20 > >=20 > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec > >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 04:14:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I36Bq-0002X7-FR; Tue, 26 Jun 2007 04:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35zD-0000yx-Kc for hipsec@ietf.org; Tue, 26 Jun 2007 04:01:19 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I35yH-00012o-D2 for hipsec@ietf.org; Tue, 26 Jun 2007 04:01:19 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l5Q80Hxe004957; Tue, 26 Jun 2007 10:00:20 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l5Q80EV5002045; Tue, 26 Jun 2007 10:00:14 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 10:00:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Hipsec] Rebuilding ICE Date: Tue, 26 Jun 2007 10:00:05 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC34B@MCHP7IDA.ww002.siemens.net> In-Reply-To: <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Rebuilding ICE Thread-Index: Ace3xi/Sc9u5asWqSNauyDjFluMYAwAAMR1g From: "Tschofenig, Hannes" To: "Andrew McGregor" , "Hannes Tschofenig" X-OriginalArrivalTime: 26 Jun 2007 08:00:14.0658 (UTC) FILETIME=[0743E220:01C7B7C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-Mailman-Approved-At: Tue, 26 Jun 2007 04:14:21 -0400 Cc: HIP WG , Marcus Brunner X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Andrew,=20 > Hannes, there was quite a long conversation in Prague about the =20 > relationship between ICE and HIP, and IIRC that's where the approach =20 > of taking ICE mechanism into HIP packet formats came from. I tried to find the meeting minutes.=20 I think =20 > the approach is valid, as the ICE formats were evolved in a =20 > completely different context. ICE is a methodology. We suggest to make extensive use of it.=20 The only "format" the ICE document suggests is the encoding of = candiates.=20 I have stated many times that one can think about a more optimized = encoding. That's OK.=20 > It's also fairly clear that there is =20 > reason to somewhat adapt ICE anyway; That's fine. For example, I wrote that you could use the RVS as a = reverse tunneling mechanism (in the spirit of TURN) to avoid using TURN. = In an upcoming draft I will explain why it still makes a lot of sense to = use TURN but that's another story.=20 it does provide us with a very =20 > well researched set of mechanisms for traversing NATs, That's also my line of thinking. Let's make use of this good work. > but it also =20 > brings along some SIP-specific baggage that could be removed without =20 > harming the NAT traversal. Jonathan tried to re-write the spec in such a way that the SIP content = is focused on a few places. He did a fairly good job although there is = still potential for improvement. I have noted (in the document) which = parts are not applicable. There aren't too many of them.=20 Ciao Hannes >=20 > Andrew >=20 > On 26/06/2007, at 7:41 PM, Hannes Tschofenig wrote: >=20 > > Hi Marcus, > > > > Thanks to Phillip Matthews and Dan Wing who actually pointed the =20 > > group to ICE. Without them there would not be a single line in the =20 > > current WG NAT traversal draft. > > > > Instead of being thankful that the group receives input from other =20 > > groups in the IETF a few individuals switched to the panic mode. > > > > Hello? > > > > In the IETF it is quite common to receive input from people that =20 > > have a different background. > > > > Ciao > > Hannes > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de] > > > Gesendet: Montag, 25. Juni 2007 20:59 > > > An: Hannes Tschofenig; HIP WG > > > Betreff: RE: [Hipsec] Rebuilding ICE > > > > > > Sorry, but I don't get where the problem really is. Looks > > > both approaches are sort of an ICE adaptation to HIP (I > > > assume Hannes not proposing the ICE for SDP encoding for HIP or?). > > > > > > If this is true, the details of both approaches must be on > > > the table. Then we can discuss. > > > > > > > > > Kind regards, > > > > > > Marcus > > > > > > --------------------------------------------------- > > > > > > Dr. Marcus Brunner > > > NEC Laboratories Europe > > > Network Division > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > > Road, London W3 6BL | Registered in England 2832014 > > > > > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Monday, June 25, 2007 2:01 PM > > > > To: 'HIP WG' > > > > Subject: [Hipsec] Rebuilding ICE > > > > > > > > I am really concerned about the current HIP NAT traversal > > > > work since one of the authors tries to re-build the ICE > > > > specification step-by-step without noticing that one could > > > > easily make us of it. > > > > > > > > I agree that you can turn any protocol in any other one if > > > > you just work hard enough. It took more than a years to > > > > figure out that there is something like ICE. How long will it > > > > take to copy it? > > > > > > > > > > > > > > > > _______________________________________________ > > > > Hipsec mailing list > > > > Hipsec@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/hipsec > > > > > > > > > > _______________________________________________ > > > Hipsec mailing list > > > Hipsec@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/hipsec > > > > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec > > >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 04:25:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I36MK-00025F-3Z; Tue, 26 Jun 2007 04:25:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I36MJ-000224-C2 for hipsec@ietf.org; Tue, 26 Jun 2007 04:25:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I36MB-0006sn-Gp for hipsec@ietf.org; Tue, 26 Jun 2007 04:25:11 -0400 Received: (qmail invoked by alias); 26 Jun 2007 08:25:02 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp041) with SMTP; 26 Jun 2007 10:25:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/M2e4BVWPMXVKdCBSym1qnHicV9all3v2WB3xkrK AOrzab1KxXj2Ed Message-ID: <4680CD5C.7050507@gmx.net> Date: Tue, 26 Jun 2007 10:25:00 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Andrew McGregor Subject: Re: [Hipsec] Rebuilding ICE References: <467FAE6D.1070807@gmx.net> <4680C323.2030709@gmx.net> <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> In-Reply-To: <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: HIP WG , Marcus Brunner X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Andrew, > Hannes, there was quite a long conversation in Prague about the > relationship between ICE and HIP, and IIRC that's where the approach > of taking ICE mechanism into HIP packet formats came from. I tried to find the meeting minutes. I think > the approach is valid, as the ICE formats were evolved in a > completely different context. ICE is a methodology. We suggest to make extensive use of it. The only "format" the ICE document suggests is the encoding of candiates. I have stated many times that one can think about a more optimized encoding. That's OK. > It's also fairly clear that there is > reason to somewhat adapt ICE anyway; That's fine. For example, I wrote that you could use the RVS as a reverse tunneling mechanism (in the spirit of TURN) to avoid using TURN. In an upcoming draft I will explain why it still makes a lot of sense to use TURN but that's another story. it does provide us with a very > well researched set of mechanisms for traversing NATs, That's also my line of thinking. Let's make use of this good work. > but it also > brings along some SIP-specific baggage that could be removed without > harming the NAT traversal. Jonathan tried to re-write the spec in such a way that the SIP content is focused on a few places. He did a fairly good job although there is still potential for improvement. I have noted (in the document) which parts are not applicable. There aren't too many of them. Ciao Hannes > > Andrew > > On 26/06/2007, at 7:41 PM, Hannes Tschofenig wrote: > > > Hi Marcus, > > > > Thanks to Phillip Matthews and Dan Wing who actually pointed the > > group to ICE. Without them there would not be a single line in the > > current WG NAT traversal draft. > > > > Instead of being thankful that the group receives input from other > > groups in the IETF a few individuals switched to the panic mode. > > > > Hello? > > > > In the IETF it is quite common to receive input from people that > > have a different background. > > > > Ciao > > Hannes > > > > > -----Ursprüngliche Nachricht----- > > > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de] > > > Gesendet: Montag, 25. Juni 2007 20:59 > > > An: Hannes Tschofenig; HIP WG > > > Betreff: RE: [Hipsec] Rebuilding ICE > > > > > > Sorry, but I don't get where the problem really is. Looks > > > both approaches are sort of an ICE adaptation to HIP (I > > > assume Hannes not proposing the ICE for SDP encoding for HIP or?). > > > > > > If this is true, the details of both approaches must be on > > > the table. Then we can discuss. > > > > > > > > > Kind regards, > > > > > > Marcus > > > > > > --------------------------------------------------- > > > > > > Dr. Marcus Brunner > > > NEC Laboratories Europe > > > Network Division > > > > > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria > > > Road, London W3 6BL | Registered in England 2832014 > > > > > > > > > > > -----Original Message----- > > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Sent: Monday, June 25, 2007 2:01 PM > > > > To: 'HIP WG' > > > > Subject: [Hipsec] Rebuilding ICE > > > > > > > > I am really concerned about the current HIP NAT traversal > > > > work since one of the authors tries to re-build the ICE > > > > specification step-by-step without noticing that one could > > > > easily make us of it. > > > > > > > > I agree that you can turn any protocol in any other one if > > > > you just work hard enough. It took more than a years to > > > > figure out that there is something like ICE. How long will it > > > > take to copy it? > > > > > > > > > > > > > > > > _______________________________________________ > > > > Hipsec mailing list > > > > Hipsec@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/hipsec > > > > > > > > > > _______________________________________________ > > > Hipsec mailing list > > > Hipsec@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/hipsec > > > > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec > > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 05:27:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37KU-0007ys-OL; Tue, 26 Jun 2007 05:27:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37KS-0007yi-W7 for hipsec@ietf.org; Tue, 26 Jun 2007 05:27:20 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I37Jg-0004LP-7n for hipsec@ietf.org; Tue, 26 Jun 2007 05:27:20 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E7106212DDE; Tue, 26 Jun 2007 12:26:30 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 90DF4212D1A; Tue, 26 Jun 2007 12:26:30 +0300 (EEST) In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC34B@MCHP7IDA.ww002.siemens.net> References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC34B@MCHP7IDA.ww002.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <251E0BEF-97CA-41C6-BCBC-1DC3156109D4@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: AW: [Hipsec] Rebuilding ICE Date: Tue, 26 Jun 2007 11:26:28 +0200 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: HIP WG , Hannes Tschofenig , Marcus Brunner X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hannes, > ICE is a methodology. We suggest to make extensive use of it. > The only "format" the ICE document suggests is the encoding of > candiates. > I have stated many times that one can think about a more optimized > encoding. That's OK. I think we all understand the basic idea of ICE being a methodology. At least I am not objecting to using it, as a methodology. However, in addition to defining the SDP encoding for the candidates, it also defines how to use STUN and TURN, so there are, indirectly, more formats and network nodes (TURN and STUN servers) built into ICE. Now, from my point of view an important architectural is not to make HIP dependent on TURN and STUN servers, nor the UDP encapsulation formats used in STUN, nor any other such details. HIP has already the rendezvous servers defined, and a well-defined mechanism for contacting hosts using the rendezvous servers. It also already has a mobility mechanism, and a rudimentary mechanism for multi-homing. I may have misunderstood, but from my point of view, using ICE terminology, HIP already seems to have the necessary mechanisms form Encoding, Offering and Answering, and Completing (I'm drawing these terms from the ICE tutorial, my apology if the spec uses other terms). What HIP is primarily missing is Gathering and Prioritising, which BTW are not a real protocol issues, and therefore most probably could be quite easily adopted from ICE, and Checking, where the past idea was to use the SHIM6 protoocol. For checking, the fact that native HIP uses both a separate protocol number of HIP control and ESP (or something else) for data traffic necessitates the ICE checking methodology to be modified anyway. The same applies, as far as I can see, also to the NAT traversal case, where HIP is using the IPsec encoding of UDP, not generic UDP. Hence, I don't think STUN applies there directly. Remember, when HIP is used the UDP and TCP messages are carried encoded somehow, typically in ESP wrappers, and therefore some of the problems specific to ICE/STUN (like port reuse) don't apply or apply in a different form. >> It's also fairly clear that there is >> reason to somewhat adapt ICE anyway; > > That's fine. For example, I wrote that you could use the RVS as a > reverse tunneling mechanism (in the spirit of TURN) to avoid using > TURN. In an upcoming draft I will explain why it still makes a lot > of sense to use TURN but that's another story. For TURN I don't understand why it would make any sense to use it, but maybe I don't understand it, again. Anyway, I would consider it undesirable to make HIP dependent on TURN. If you would like to allow *optional* use of TURN, them I'm fine. As long as the base HIP mechanisms would work with only one new piece of infrastructure, the RVS servers. But I really would like to hear your detailed list of issues on the table. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 05:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37SH-0006EX-2b; Tue, 26 Jun 2007 05:35:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37SF-0006CG-15 for hipsec@ietf.org; Tue, 26 Jun 2007 05:35:23 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I37S4-0005o9-Uj for hipsec@ietf.org; Tue, 26 Jun 2007 05:35:23 -0400 Received: (qmail invoked by alias); 26 Jun 2007 08:35:03 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp045) with SMTP; 26 Jun 2007 10:35:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8zM0qQmj8BK8eIAM/mye0KtN5y2MH2Dyg+W5TNC v4ltKyfvNGpq+j Message-ID: <4680CFB5.5020904@gmx.net> Date: Tue, 26 Jun 2007 10:35:01 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [Hipsec] Rebuilding ICE References: <467FAE6D.1070807@gmx.net> <4680C323.2030709@gmx.net> <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> <3D4C521F-8586-4B49-A32B-6BE8D42A18BF@netlab.nec.de> In-Reply-To: <3D4C521F-8586-4B49-A32B-6BE8D42A18BF@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Martin, thanks for your feedback and the assessment. I also believe that the problems stated somewhere along the lines of modifying the scope of draft-ietf-hip-nat-traversal-01. Here is what other working groups did. They essentially split the problem parts into separate chunks: a) UDP Encapsulation of data traffic and signaling traffic b) Allowing signaling messages to traverse a NAT (or firewall) This would essentially be the communication between the end host and the RVS. c) Traversal of NATs (and firewalls) when it comes to end-to-end communication for data traffic ICE focuses on item (c). In SIP (a) and (b) are handled differently and also covered by different documents (i.e., outside the scope of ICE). In SIP, for example, STUN is not used to perform NAT traversal of the SIP messages exchanged between the SIP UA and the outbound proxy. With the discussions regarding ICE for HIP we focused on item (c) only. For example, there is nothing wrong with defining UDP encapsulation of signaling messages and data traffic as suggested in draft-ietf-hip-nat-traversal-01. Ciao Hannes Martin Stiemerling wrote: > Hi all, > > I think that the discussion slipped off the actually topic a bit. The > main questions are basically: > 1. the current HIP NAT traversal draft (draft-ietf-hip-nat-traversal-01) > 2. using ICE and HIP in one way or the other > > For 1: > There is some disagreement between the authors of the draft on how to > continue with the draft as the WG approved approach > (draft-ietf-hip-nat-traversal-01) and the current approach in the > upcoming draft are fundamental different. We have asked the chairs > about their opinion on this but have not received any answer. > IMHO I do not like the approach taken right now on rebuilding ICE and > something different. I do like much more the simple approach take in > draft-ietf-hip-nat-traversal-01 as we need to get a start on HIP's NAT > traversal. > > For 2: > Using something as ICE (must not be directly ICE, i.e., subject to > further discussions) could be helpful for HIP's NAT traversal. BUT: > The WG has agreed on the approach in draft-ietf-hip-nat-traversal-01 > and not on something different. Furthermore, I do think it is much > more worth on completing existing work and to bring it to the field > for further testing and studying (remember it is an experimental draft > only!). > So, why not finishing things up first and going than for something > different? > > Thanks, > > Martin > > Am 26.06.2007 um 09:47 schrieb Andrew McGregor: > >> Hannes, there was quite a long conversation in Prague about the >> relationship between ICE and HIP, and IIRC that's where the approach >> of taking ICE mechanism into HIP packet formats came from. I think >> the approach is valid, as the ICE formats were evolved in a >> completely different context. It's also fairly clear that there is >> reason to somewhat adapt ICE anyway; it does provide us with a very >> well researched set of mechanisms for traversing NATs, but it also >> brings along some SIP-specific baggage that could be removed without >> harming the NAT traversal. >> >> Andrew >> >> On 26/06/2007, at 7:41 PM, Hannes Tschofenig wrote: >> >>> Hi Marcus, >>> >>> Thanks to Phillip Matthews and Dan Wing who actually pointed the >>> group to ICE. Without them there would not be a single line in the >>> current WG NAT traversal draft. >>> >>> Instead of being thankful that the group receives input from other >>> groups in the IETF a few individuals switched to the panic mode. >>> >>> Hello? >>> >>> In the IETF it is quite common to receive input from people that >>> have a different background. >>> >>> Ciao >>> Hannes >>> >>> > -----Ursprüngliche Nachricht----- >>> > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de] >>> > Gesendet: Montag, 25. Juni 2007 20:59 >>> > An: Hannes Tschofenig; HIP WG >>> > Betreff: RE: [Hipsec] Rebuilding ICE >>> > >>> > Sorry, but I don't get where the problem really is. Looks >>> > both approaches are sort of an ICE adaptation to HIP (I >>> > assume Hannes not proposing the ICE for SDP encoding for HIP or?). >>> > >>> > If this is true, the details of both approaches must be on >>> > the table. Then we can discuss. >>> > >>> > >>> > Kind regards, >>> > >>> > Marcus >>> > >>> > --------------------------------------------------- >>> > >>> > Dr. Marcus Brunner >>> > NEC Laboratories Europe >>> > Network Division >>> > >>> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>> > Road, London W3 6BL | Registered in England 2832014 >>> > >>> > > >>> > > -----Original Message----- >>> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> > > Sent: Monday, June 25, 2007 2:01 PM >>> > > To: 'HIP WG' >>> > > Subject: [Hipsec] Rebuilding ICE >>> > > >>> > > I am really concerned about the current HIP NAT traversal >>> > > work since one of the authors tries to re-build the ICE >>> > > specification step-by-step without noticing that one could >>> > > easily make us of it. >>> > > >>> > > I agree that you can turn any protocol in any other one if >>> > > you just work hard enough. It took more than a years to >>> > > figure out that there is something like ICE. How long will it >>> > > take to copy it? >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > Hipsec mailing list >>> > > Hipsec@lists.ietf.org >>> > > https://www1.ietf.org/mailman/listinfo/hipsec >>> > > >>> > >>> > _______________________________________________ >>> > Hipsec mailing list >>> > Hipsec@lists.ietf.org >>> > https://www1.ietf.org/mailman/listinfo/hipsec >>> > >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >>> >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 07:27:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I39CF-000128-O8; Tue, 26 Jun 2007 07:26:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I39CE-000123-9x for hipsec@ietf.org; Tue, 26 Jun 2007 07:26:58 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I39CD-00043I-0S for hipsec@ietf.org; Tue, 26 Jun 2007 07:26:58 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 401D813CF81; Tue, 26 Jun 2007 13:26:48 +0200 (CEST) In-Reply-To: <4680CFB5.5020904@gmx.net> References: <467FAE6D.1070807@gmx.net> <4680C323.2030709@gmx.net> <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> <3D4C521F-8586-4B49-A32B-6BE8D42A18BF@netlab.nec.de> <4680CFB5.5020904@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8FC1E603-D5FD-4356-A75C-915CC20218CC@netlab.nec.de> From: Martin Stiemerling Subject: Re: [Hipsec] Rebuilding ICE Date: Tue, 26 Jun 2007 13:26:47 +0200 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0577153201==" Errors-To: hipsec-bounces@lists.ietf.org --===============0577153201== Content-Type: multipart/alternative; boundary=Apple-Mail-17-539060777 --Apple-Mail-17-539060777 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Am 26.06.2007 um 10:35 schrieb Hannes Tschofenig: > Hi Martin, > > thanks for your feedback and the assessment. > > I also believe that the problems stated somewhere along the lines =20 > of modifying the scope of draft-ietf-hip-nat-traversal-01. > > Here is what other working groups did. They essentially split the =20 > problem parts into separate chunks: > > a) UDP Encapsulation of data traffic and signaling traffic > b) Allowing signaling messages to traverse a NAT (or firewall) > This would essentially be the communication between the end host =20 > and the RVS. > c) Traversal of NATs (and firewalls) when it comes to end-to-end =20 > communication for data traffic > > ICE focuses on item (c). In SIP (a) and (b) are handled differently =20= > and also covered by different documents (i.e., outside the scope of =20= > ICE). In SIP, for example, > STUN is not used to perform NAT traversal of the SIP messages =20 > exchanged between the SIP UA and the outbound proxy. > > With the discussions regarding ICE for HIP we focused on item (c) =20 > only. For example, there is nothing wrong with defining UDP =20 > encapsulation of signaling messages and data traffic as suggested =20 > in draft-ietf-hip-nat-traversal-01. It seems that we are on the same line :) I also see draft-ietf-hip-nat-traversal-01 along the lines of a) and =20 b). Point c) is out of scope of the WG draft draft-ietf-hip-nat-=20 traversal-01, as we targeting to a nice, small solution to get some =20 first hand experience with HIP and NATs. Cheers, Martin > > Ciao > Hannes > > Martin Stiemerling wrote: >> Hi all, >> >> I think that the discussion slipped off the actually topic a bit. =20 >> The main questions are basically: >> 1. the current HIP NAT traversal draft (draft-ietf-hip-nat-=20 >> traversal-01) >> 2. using ICE and HIP in one way or the other >> >> For 1: >> There is some disagreement between the authors of the draft on how =20= >> to continue with the draft as the WG approved approach (draft-ietf-=20= >> hip-nat-traversal-01) and the current approach in the upcoming =20 >> draft are fundamental different. We have asked the chairs about =20 >> their opinion on this but have not received any answer. >> IMHO I do not like the approach taken right now on rebuilding ICE =20 >> and something different. I do like much more the simple approach =20 >> take in draft-ietf-hip-nat-traversal-01 as we need to get a start =20 >> on HIP's NAT traversal. >> >> For 2: >> Using something as ICE (must not be directly ICE, i.e., subject to =20= >> further discussions) could be helpful for HIP's NAT traversal. =20 >> BUT: The WG has agreed on the approach in draft-ietf-hip-nat-=20 >> traversal-01 and not on something different. Furthermore, I do =20 >> think it is much more worth on completing existing work and to =20 >> bring it to the field for further testing and studying (remember =20 >> it is an experimental draft only!). >> So, why not finishing things up first and going than for something =20= >> different? >> >> Thanks, >> >> Martin >> >> Am 26.06.2007 um 09:47 schrieb Andrew McGregor: >> >>> Hannes, there was quite a long conversation in Prague about the =20 >>> relationship between ICE and HIP, and IIRC that's where the =20 >>> approach of taking ICE mechanism into HIP packet formats came =20 >>> from. I think the approach is valid, as the ICE formats were =20 >>> evolved in a completely different context. It's also fairly =20 >>> clear that there is reason to somewhat adapt ICE anyway; it does =20 >>> provide us with a very well researched set of mechanisms for =20 >>> traversing NATs, but it also brings along some SIP-specific =20 >>> baggage that could be removed without harming the NAT traversal. >>> >>> Andrew >>> >>> On 26/06/2007, at 7:41 PM, Hannes Tschofenig wrote: >>> >>>> Hi Marcus, >>>> >>>> Thanks to Phillip Matthews and Dan Wing who actually pointed the =20= >>>> group to ICE. Without them there would not be a single line in =20 >>>> the current WG NAT traversal draft. >>>> >>>> Instead of being thankful that the group receives input from =20 >>>> other groups in the IETF a few individuals switched to the panic =20= >>>> mode. >>>> >>>> Hello? >>>> >>>> In the IETF it is quite common to receive input from people that =20= >>>> have a different background. >>>> >>>> Ciao >>>> Hannes >>>> >>>> > -----Urspr=FCngliche Nachricht----- >>>> > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de] >>>> > Gesendet: Montag, 25. Juni 2007 20:59 >>>> > An: Hannes Tschofenig; HIP WG >>>> > Betreff: RE: [Hipsec] Rebuilding ICE >>>> > >>>> > Sorry, but I don't get where the problem really is. Looks >>>> > both approaches are sort of an ICE adaptation to HIP (I >>>> > assume Hannes not proposing the ICE for SDP encoding for HIP =20 >>>> or?). >>>> > >>>> > If this is true, the details of both approaches must be on >>>> > the table. Then we can discuss. >>>> > >>>> > >>>> > Kind regards, >>>> > >>>> > Marcus >>>> > >>>> > --------------------------------------------------- >>>> > >>>> > Dr. Marcus Brunner >>>> > NEC Laboratories Europe >>>> > Network Division >>>> > >>>> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>> > Road, London W3 6BL | Registered in England 2832014 >>>> > >>>> > > >>>> > > -----Original Message----- >>>> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> > > Sent: Monday, June 25, 2007 2:01 PM >>>> > > To: 'HIP WG' >>>> > > Subject: [Hipsec] Rebuilding ICE >>>> > > >>>> > > I am really concerned about the current HIP NAT traversal >>>> > > work since one of the authors tries to re-build the ICE >>>> > > specification step-by-step without noticing that one could >>>> > > easily make us of it. >>>> > > >>>> > > I agree that you can turn any protocol in any other one if >>>> > > you just work hard enough. It took more than a years to >>>> > > figure out that there is something like ICE. How long will it >>>> > > take to copy it? >>>> > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > Hipsec mailing list >>>> > > Hipsec@lists.ietf.org >>>> > > https://www1.ietf.org/mailman/listinfo/hipsec >>>> > > >>>> > >>>> > _______________________________________________ >>>> > Hipsec mailing list >>>> > Hipsec@lists.ietf.org >>>> > https://www1.ietf.org/mailman/listinfo/hipsec >>>> > >>>> >>>> _______________________________________________ >>>> Hipsec mailing list >>>> Hipsec@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/hipsec >>>> >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >> >> stiemerling@netlab.nec.de >> NEC Europe Limited | Registered Office: NEC House, 1 Victoria =20 >> Road, London W3 6BL | Registered in England 2832014 >> >> >> >> ---------------------------------------------------------------------=20= >> --- >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> > stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, =20 London W3 6BL | Registered in England 2832014 --Apple-Mail-17-539060777 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Am 26.06.2007 um = 10:35 schrieb Hannes Tschofenig:

Hi Martin,

thanks for your feedback and the = assessment.

I also believe that the problems stated somewhere = along the lines of modifying the scope of = draft-ietf-hip-nat-traversal-01.

Here is what other working = groups did. They essentially split the problem parts into separate = chunks:

a) UDP Encapsulation of data traffic and signaling = traffic
b) Allowing signaling messages = to traverse a NAT (or firewall)
This would = essentially be the communication between the end host and the = RVS.
c) Traversal of NATs (and = firewalls) when it comes to end-to-end communication for data = traffic

ICE focuses on item (c). In SIP (a) and (b) are = handled differently and also covered by different documents (i.e., = outside the scope of ICE). In SIP, for example,
STUN is not used to perform NAT traversal of the SIP = messages exchanged between the SIP UA and the outbound proxy.

With the = discussions regarding ICE for HIP we focused on item (c) only. For = example, there is nothing wrong with defining UDP encapsulation of = signaling messages and data traffic as suggested in = draft-ietf-hip-nat-traversal-01.

It seems that we are on the = same line :)

I = also see=A0draft-ietf-hip-nat-traversal-01 along the lines of a) and b). = Point c) is out of scope of the WG = draft=A0draft-ietf-hip-nat-traversal-01, as we=A0targeting to a nice, = small solution to get some first hand experience with HIP and = NATs.=A0

Cheers,

=A0 = Martin


Ciao
Hannes

Martin Stiemerling wrote:
=
Hi all,

I think = that the discussion slipped off the actually topic a bit. The main = questions are basically:
1. the = current HIP NAT traversal draft = (draft-ietf-hip-nat-traversal-01)
2. using ICE = and HIP in one way or the other

For 1:
There is some disagreement between the authors of = the draft on how to continue with the draft as the WG approved approach = (draft-ietf-hip-nat-traversal-01) and the current approach in the = upcoming draft are fundamental different. We have asked the chairs about = their opinion on this but have not received any answer.
IMHO I do not like the approach taken right now on = rebuilding ICE and something different. I do like much more the simple = approach take in draft-ietf-hip-nat-traversal-01 as we need to get a = start on HIP's NAT traversal.

For 2:
Using something as ICE (must not be directly ICE, = i.e., subject to further discussions) could be helpful for HIP's NAT = traversal. BUT: The WG has agreed on the approach in = draft-ietf-hip-nat-traversal-01 and not on something different. = Furthermore, I do think it is much more worth on completing existing = work and to bring it to the field for further testing and studying = (remember it is an experimental draft only!).
So, why not finishing things up first and going than = for something different?

Thanks,

=A0 Martin

Am = 26.06.2007 um 09:47 schrieb Andrew McGregor:

Hannes, there was quite a long = conversation in Prague about the relationship between ICE and HIP, and = IIRC that's where the approach of taking ICE mechanism into HIP packet = formats came from.=A0 I = think the approach is valid, as the ICE formats were evolved in a = completely different context.=A0 = It's also fairly clear that there is reason to somewhat adapt ICE = anyway; it does provide us with a very well researched set of mechanisms = for traversing NATs, but it also brings along some SIP-specific baggage = that could be removed without harming the NAT traversal.


On 26/06/2007, at 7:41 PM, Hannes Tschofenig = wrote:

=
Hi Marcus,

Thanks = to Phillip Matthews and Dan Wing who actually pointed the group to ICE. = Without them there would not be a single line in the current WG NAT = traversal draft.

Instead of being thankful that the group receives = input from other groups in the IETF a few individuals switched to the = panic mode.

Hello?

In the IETF it is quite common = to receive input from people that have a different background.

Hannes

> = -----Urspr=FCngliche Nachricht-----
> Von: = Marcus Brunner [mailto:Brunner@netlab.nec.de]
> Gesendet: Montag, 25. Juni 2007 20:59
> An: Hannes Tschofenig; HIP WG
> Betreff: RE: [Hipsec] Rebuilding ICE
>
> Sorry, = but I don't get where the problem really is. Looks
> both approaches are sort of an ICE adaptation = to HIP (I
> assume Hannes not proposing = the ICE for SDP encoding for HIP or?).
> If this is true, the = details of both approaches must be on
> the = table. Then we can discuss.
>
> Kind regards,
> Marcus
>
> = ---------------------------------------------------
>
> Dr. = Marcus Brunner
> NEC Laboratories = Europe
> Network Division
>
> NEC = Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL | Registered in England = 2832014
>
>=A0 = >
> > -----Original = Message-----
> > From: Hannes = Tschofenig [mailto:Hannes.Tschofenig@gmx.net= ]
> > Sent: Monday, June 25, = 2007 2:01 PM
> > To: 'HIP WG'
> > Subject: [Hipsec] Rebuilding ICE
> >
> > I = am really concerned about the current HIP NAT traversal
> > work since one of the authors tries to = re-build the ICE
> > specification = step-by-step without noticing that one could
> > easily make us of it.
> >
> > I = agree that you can turn any protocol in any other one if
> > you just work hard enough. It took more = than a years to
> > figure out that there = is something like ICE. How long will it
> = > take to copy it?
> >
> >
> = >
> > = _______________________________________________
> > Hipsec mailing list
> = >
>
> = _______________________________________________
> Hipsec mailing list

Hipsec mailing list



Hipsec mailing list

stiemerling@netlab.nec.de
NEC Europe Limited | Registered Office: NEC House, 1 = Victoria Road, London W3 6BL | Registered in England 2832014




Hipsec mailing list

=A0=A0


=

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=

= --Apple-Mail-17-539060777-- --===============0577153201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0577153201==-- From hipsec-bounces@lists.ietf.org Tue Jun 26 09:42:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3BJb-0003CJ-UD; Tue, 26 Jun 2007 09:42:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3BJa-0003Bm-6L for hipsec@ietf.org; Tue, 26 Jun 2007 09:42:42 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3BJZ-0004VW-Kb for hipsec@ietf.org; Tue, 26 Jun 2007 09:42:42 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I3BJ2-0006bV-0z; Tue, 26 Jun 2007 09:42:08 -0400 In-Reply-To: References: <69DA200E-6FBA-4965-928E-5FD4D585F79E@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Philip Matthews Subject: Re: [Hipsec] I-D on using HIP for P2PSIP: Date: Tue, 26 Jun 2007 09:42:13 -0400 To: Martin Stiemerling X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: HIP WG , Alan Johnston , Eric Cooper , hipsec-rg@listserv.cybertrust.com X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1807499643==" Errors-To: hipsec-bounces@lists.ietf.org --===============1807499643== Content-Type: multipart/alternative; boundary=Apple-Mail-15-547187477 --Apple-Mail-15-547187477 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Martin: Very interesting! Can you share any details on your prototype? Is it similar to our proposal? - Philip On 26-Jun-07, at 03:58 , Martin Stiemerling wrote: > Hi Philip, > > Just to let you know: We have a P2PSIP prototype already using HIP > for building and running the overlay. > > Martin > > Am 18.06.2007 um 21:49 schrieb Philip Matthews: > >> Folks: >> >> I would like to call your attention to a draft that was just >> submitted to the P2PSIP working group. >> This document proposes to use HIP as the basis in forming a P2PSIP >> overlay network. >> >> The draft is a high-level draft that is trying to sell the P2PSIP >> group on the idea of using HIP, rather than a detailed design. So we >> simply sketch the ideas in a broad fashion, rather than giving >> precise details. However, the authors still feel the draft will >> likely be of interest to the HIP community. >> >> In particular, what is likely of greatest interest are the four HIP >> extensions that the draft proposes: >> * Defining how to route HIP packets though intermediate peers in an >> overlay; >> * Adding a new HIP packet type (which we call the Data packet) to >> transport upper-layer protocols >> in the overlay when the transmission path goes through one or >> more intermediate peers; >> * Extending the procedures for establishing a HIP association to the >> case where a peer wants to join an overlay; >> * Proposing alternative transport stack for protocols where running >> over ESP is undesirable (e.g. Secure RTP transport of voice packets). >> >> The authors would be very interested in getting feedback from the HIP >> community on these proposed extensions. >> >> From a HIP prospective, what is interesting is that this approach >> provides a motivation for people to use HIP, because it is using HIP >> in a "closed" system: a peer-to-peer overlay. >> >> The document was just submitted on the weekend, and had not yet >> appeared in archives when this was written. >> Until it does, you can get a copy at: >> http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- >> hop-00.txt >> or an HTML version at: >> http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- >> hop-00.htm >> >> - Philip >> >> [I am cross-posting this to the HIP RG list, but after discussion >> with Gonzalo, we think that the HIP WG mailing list is the best place >> to discuss the details of the proposed HIP extensions. However, if >> you have any general comments on the suitability of HIP for P2PSIP, >> or general comments on the draft, then those comments are best >> directed to the P2PSIP list.] >> >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > --Apple-Mail-15-547187477 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Martin:

Very = interesting!

Can you share any details = on your prototype?
Is it similar to our = proposal?

- = Philip

On 26-Jun-07, at 03:58 , Martin = Stiemerling wrote:

Hi = Philip,

Just to let = you know: We have a P2PSIP prototype already using HIP for building and = running the overlay.=A0

=A0Martin
=A0
Am 18.06.2007 um 21:49 schrieb Philip Matthews:

Folks:

I would like to call your = attention to a draft that was just =A0
This = document proposes to use HIP as the basis in forming a P2PSIP =A0
overlay = network.

The draft is a high-level draft that is trying to = sell the P2PSIP =A0
group on the idea of using HIP, rather than a = detailed design. So we =A0
simply = sketch the ideas in a broad fashion, rather than giving =A0
precise = details. However, the authors still feel the draft will =A0
likely = be of interest to the HIP community.

In particular, what is likely of = greatest interest are the four HIP =A0
*=A0 Defining how to route HIP = packets though intermediate peers in an =A0
*=A0 Adding a new HIP packet type = (which we call the Data packet) to =A0
=A0 =A0 in the overlay when the = transmission path goes through one or =A0
more = intermediate peers;
*=A0 Extending the procedures for = establishing a HIP association to the =A0
case = where a peer wants to join an overlay;
*=A0 Proposing alternative = transport stack for protocols where running =A0
over ESP = is undesirable (e.g. Secure RTP transport of voice packets).

The = authors would be very interested in getting feedback from the HIP =A0

=A0=46rom a HIP prospective, what = is interesting is that this approach =A0
provides = a motivation for people to use HIP, because it is using HIP =A0
in a = "closed" system: a peer-to-peer overlay.

The document = was just submitted on the weekend, and had not yet =A0
appeared = in archives when this was written.
Until it = does, you can get a copy at:
or an HTML version at:

- Philip

[I am cross-posting this to the = HIP RG list, but after discussion =A0
with = Gonzalo, we think that the HIP WG mailing list is the best place =A0
to = discuss the details of the proposed HIP extensions. However, if =A0
you have = any general comments on the suitability of HIP for P2PSIP, =A0
or = general comments on the draft, then those comments are best =A0
directed = to the P2PSIP list.]


Hipsec mailing list

stiemerling@netlab.nec.de
NEC Europe Limited |=A0Registered Office: NEC House, = 1 Victoria Road, London W3 6BL |=A0Registered in England = 2832014

=


= --Apple-Mail-15-547187477-- --===============1807499643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1807499643==-- From hipsec-bounces@lists.ietf.org Tue Jun 26 10:57:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CTv-0006rh-FF; Tue, 26 Jun 2007 10:57:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3CTu-0006rZ-JA for hipsec@ietf.org; Tue, 26 Jun 2007 10:57:26 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3CT5-00048z-Tt for hipsec@ietf.org; Tue, 26 Jun 2007 10:57:26 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5QEuRXW022625; Tue, 26 Jun 2007 17:56:33 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 17:56:20 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 17:56:20 +0300 Received: from [172.21.39.150] (esdhcp039150.research.nokia.com [172.21.39.150]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5QEuIhx023211; Tue, 26 Jun 2007 17:56:18 +0300 In-Reply-To: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC2F6@MCHP7IDA.ww002.siemens.net> References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC2F6@MCHP7IDA.ww002.siemens.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8B8969AC-3F60-4B2E-8D27-20C520DBF32D@nokia.com> From: Lars Eggert Subject: Re: AW: [Hipsec] Rebuilding ICE Date: Tue, 26 Jun 2007 17:56:16 +0300 To: "ext Tschofenig, Hannes" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Jun 2007 14:56:20.0174 (UTC) FILETIME=[27DF4EE0:01C7B802] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: HIP WG , Hannes Tschofenig , Marcus Brunner X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1724925894==" Errors-To: hipsec-bounces@lists.ietf.org --===============1724925894== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-66-551630097; protocol="application/pkcs7-signature" --Apple-Mail-66-551630097 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-6-26, at 10:03, ext Tschofenig, Hannes wrote: > Thanks to Phillip Matthews and Dan Wing who actually pointed the > group to ICE. Without them there would not be a single line in the > current WG NAT traversal draft. > > Instead of being thankful that the group receives input from other > groups in the IETF a few individuals swiched to the panic mode. I'm still catching up on this thread, but in several email messages I've read so far, Miika has acknowledged that the idea of adopting ICE concepts for HIP NAT traversal originated with Phillip. The acknowledgment section of his draft also credits Phillip. To me, this looks like the editor of the WG document is giving credit where credit is due, on behalf of the working group. Lars --Apple-Mail-66-551630097 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA2MjYxNDU2MTdaMCMGCSqGSIb3DQEJBDEWBBTCkDRQMRu0oeer LdxXkN34IBWCwjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAvYidlF1hRkaZ0t2rNytrY6WWOJvQreBl1/7F9VN2soP8k4OqT4Sa PtQNaCXu4KC2cvldXahwAL4q6FpeTrr84TltT3ZOvFMelXCuE8E7W+9KeOtwQt/5zxuDH9HCGy1q c2Ts54tYPQSKlMQsf5l4SbGyv3Y6kBW1sDBrJnllDkyoA1TSBBU3XmCN81ar/TKRlORZU0jRP7HK yozHh8Fyu/8w1ZlMICBJrXYYC37dIA2lGB98PBZwY8vyOCCFLqy4gk+IpmYS1EjN5DYOPT58a1rG BTmC9znjBbfUvoQUHkkTFdrrvaLfhmWW0zo1Vlk9QJfdNreAkHMl2lbO1fVZ5gAAAAAAAA== --Apple-Mail-66-551630097-- --===============1724925894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1724925894==-- From hipsec-bounces@lists.ietf.org Tue Jun 26 11:15:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Clm-0002cH-A9; Tue, 26 Jun 2007 11:15:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Cll-0002cB-0m for hipsec@ietf.org; Tue, 26 Jun 2007 11:15:53 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3Clf-0001Dm-EO for hipsec@ietf.org; Tue, 26 Jun 2007 11:15:52 -0400 Received: (qmail invoked by alias); 26 Jun 2007 15:15:46 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp058) with SMTP; 26 Jun 2007 17:15:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/2PTNjaWP2pSrC0/dXLs1nZZStxfAOc8yWP92shh k/jB7QoD6CFafv Message-ID: <46812DA2.4060701@gmx.net> Date: Tue, 26 Jun 2007 17:15:46 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [Hipsec] Rebuilding ICE References: <467FAE6D.1070807@gmx.net> <4680C323.2030709@gmx.net> <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> <3D4C521F-8586-4B49-A32B-6BE8D42A18BF@netlab.nec.de> <4680CFB5.5020904@gmx.net> <8FC1E603-D5FD-4356-A75C-915CC20218CC@netlab.nec.de> In-Reply-To: <8FC1E603-D5FD-4356-A75C-915CC20218CC@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Martin, Martin Stiemerling wrote: > > Am 26.06.2007 um 10:35 schrieb Hannes Tschofenig: > >> Hi Martin, >> >> thanks for your feedback and the assessment. >> >> I also believe that the problems stated somewhere along the lines of >> modifying the scope of draft-ietf-hip-nat-traversal-01. >> >> Here is what other working groups did. They essentially split the >> problem parts into separate chunks: >> >> a) UDP Encapsulation of data traffic and signaling traffic >> b) Allowing signaling messages to traverse a NAT (or firewall) >> This would essentially be the communication between the end host and >> the RVS. >> c) Traversal of NATs (and firewalls) when it comes to end-to-end >> communication for data traffic >> >> ICE focuses on item (c). In SIP (a) and (b) are handled differently >> and also covered by different documents (i.e., outside the scope of >> ICE). In SIP, for example, >> STUN is not used to perform NAT traversal of the SIP messages >> exchanged between the SIP UA and the outbound proxy. >> >> With the discussions regarding ICE for HIP we focused on item (c) >> only. For example, there is nothing wrong with defining UDP >> encapsulation of signaling messages and data traffic as suggested in >> draft-ietf-hip-nat-traversal-01. > > It seems that we are on the same line :) > > I also see draft-ietf-hip-nat-traversal-01 along the lines of a) and > b). Point c) is out of scope of the WG draft > draft-ietf-hip-nat-traversal-01, as we targeting to a nice, small > solution to get some first hand experience with HIP and NATs. > That's a good point. The scope of the document changed a bit. Maybe the first thing to think about is the scope of the work. Ciao Hannes > Cheers, > > Martin > >> >> Ciao >> Hannes >> >> Martin Stiemerling wrote: >>> Hi all, >>> >>> I think that the discussion slipped off the actually topic a bit. >>> The main questions are basically: >>> 1. the current HIP NAT traversal draft >>> (draft-ietf-hip-nat-traversal-01) >>> 2. using ICE and HIP in one way or the other >>> >>> For 1: >>> There is some disagreement between the authors of the draft on how >>> to continue with the draft as the WG approved approach >>> (draft-ietf-hip-nat-traversal-01) and the current approach in the >>> upcoming draft are fundamental different. We have asked the chairs >>> about their opinion on this but have not received any answer. >>> IMHO I do not like the approach taken right now on rebuilding ICE >>> and something different. I do like much more the simple approach >>> take in draft-ietf-hip-nat-traversal-01 as we need to get a start on >>> HIP's NAT traversal. >>> >>> For 2: >>> Using something as ICE (must not be directly ICE, i.e., subject to >>> further discussions) could be helpful for HIP's NAT traversal. BUT: >>> The WG has agreed on the approach in draft-ietf-hip-nat-traversal-01 >>> and not on something different. Furthermore, I do think it is much >>> more worth on completing existing work and to bring it to the field >>> for further testing and studying (remember it is an experimental >>> draft only!). >>> So, why not finishing things up first and going than for something >>> different? >>> >>> Thanks, >>> >>> Martin >>> >>> Am 26.06.2007 um 09:47 schrieb Andrew McGregor: >>> >>>> Hannes, there was quite a long conversation in Prague about the >>>> relationship between ICE and HIP, and IIRC that's where the >>>> approach of taking ICE mechanism into HIP packet formats came >>>> from. I think the approach is valid, as the ICE formats were >>>> evolved in a completely different context. It's also fairly clear >>>> that there is reason to somewhat adapt ICE anyway; it does provide >>>> us with a very well researched set of mechanisms for traversing >>>> NATs, but it also brings along some SIP-specific baggage that could >>>> be removed without harming the NAT traversal. >>>> >>>> Andrew >>>> >>>> On 26/06/2007, at 7:41 PM, Hannes Tschofenig wrote: >>>> >>>>> Hi Marcus, >>>>> >>>>> Thanks to Phillip Matthews and Dan Wing who actually pointed the >>>>> group to ICE. Without them there would not be a single line in the >>>>> current WG NAT traversal draft. >>>>> >>>>> Instead of being thankful that the group receives input from other >>>>> groups in the IETF a few individuals switched to the panic mode. >>>>> >>>>> Hello? >>>>> >>>>> In the IETF it is quite common to receive input from people that >>>>> have a different background. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> > -----Ursprüngliche Nachricht----- >>>>> > Von: Marcus Brunner [mailto:Brunner@netlab.nec.de] >>>>> > Gesendet: Montag, 25. Juni 2007 20:59 >>>>> > An: Hannes Tschofenig; HIP WG >>>>> > Betreff: RE: [Hipsec] Rebuilding ICE >>>>> > >>>>> > Sorry, but I don't get where the problem really is. Looks >>>>> > both approaches are sort of an ICE adaptation to HIP (I >>>>> > assume Hannes not proposing the ICE for SDP encoding for HIP or?). >>>>> > >>>>> > If this is true, the details of both approaches must be on >>>>> > the table. Then we can discuss. >>>>> > >>>>> > >>>>> > Kind regards, >>>>> > >>>>> > Marcus >>>>> > >>>>> > --------------------------------------------------- >>>>> > >>>>> > Dr. Marcus Brunner >>>>> > NEC Laboratories Europe >>>>> > Network Division >>>>> > >>>>> > NEC Europe Limited | Registered Office: NEC House, 1 Victoria >>>>> > Road, London W3 6BL | Registered in England 2832014 >>>>> > >>>>> > > >>>>> > > -----Original Message----- >>>>> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> > > Sent: Monday, June 25, 2007 2:01 PM >>>>> > > To: 'HIP WG' >>>>> > > Subject: [Hipsec] Rebuilding ICE >>>>> > > >>>>> > > I am really concerned about the current HIP NAT traversal >>>>> > > work since one of the authors tries to re-build the ICE >>>>> > > specification step-by-step without noticing that one could >>>>> > > easily make us of it. >>>>> > > >>>>> > > I agree that you can turn any protocol in any other one if >>>>> > > you just work hard enough. It took more than a years to >>>>> > > figure out that there is something like ICE. How long will it >>>>> > > take to copy it? >>>>> > > >>>>> > > >>>>> > > >>>>> > > _______________________________________________ >>>>> > > Hipsec mailing list >>>>> > > Hipsec@lists.ietf.org >>>>> > > https://www1.ietf.org/mailman/listinfo/hipsec >>>>> > > >>>>> > >>>>> > _______________________________________________ >>>>> > Hipsec mailing list >>>>> > Hipsec@lists.ietf.org >>>>> > https://www1.ietf.org/mailman/listinfo/hipsec >>>>> > >>>>> >>>>> _______________________________________________ >>>>> Hipsec mailing list >>>>> Hipsec@lists.ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/hipsec >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Hipsec mailing list >>>> Hipsec@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/hipsec >>> >>> stiemerling@netlab.nec.de >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, >>> London W3 6BL | Registered in England 2832014 >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >>> >> > > stiemerling@netlab.nec.de > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, > London W3 6BL | Registered in England 2832014 > > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 11:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3DAP-0006lp-69; Tue, 26 Jun 2007 11:41:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3DAN-0006dD-Aj for hipsec@ietf.org; Tue, 26 Jun 2007 11:41:19 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3D9b-00086y-QI for hipsec@ietf.org; Tue, 26 Jun 2007 11:41:18 -0400 Received: (qmail invoked by alias); 26 Jun 2007 15:13:51 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp030) with SMTP; 26 Jun 2007 17:13:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX196DechGp567ctB2I9Gw03xMNSgCb/AHiRt76YfqY KlsBe3gFps58um Message-ID: <46812D28.8050906@gmx.net> Date: Tue, 26 Jun 2007 17:13:44 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Lars Eggert Subject: Re: AW: [Hipsec] Rebuilding ICE References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC2F6@MCHP7IDA.ww002.siemens.net> <8B8969AC-3F60-4B2E-8D27-20C520DBF32D@nokia.com> In-Reply-To: <8B8969AC-3F60-4B2E-8D27-20C520DBF32D@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Marcus Brunner , "ext Tschofenig, Hannes" , HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org That's certainly good. Maybe the entire discussion start wasn't that great.... Let's see how we move forward. Ciao Hannes Lars Eggert wrote: > On 2007-6-26, at 10:03, ext Tschofenig, Hannes wrote: >> Thanks to Phillip Matthews and Dan Wing who actually pointed the >> group to ICE. Without them there would not be a single line in the >> current WG NAT traversal draft. >> >> Instead of being thankful that the group receives input from other >> groups in the IETF a few individuals swiched to the panic mode. > > I'm still catching up on this thread, but in several email messages > I've read so far, Miika has acknowledged that the idea of adopting ICE > concepts for HIP NAT traversal originated with Phillip. The > acknowledgment section of his draft also credits Phillip. > > To me, this looks like the editor of the WG document is giving credit > where credit is due, on behalf of the working group. > > Lars > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 13:01:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3EQA-0004qz-TN; Tue, 26 Jun 2007 13:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3EQA-0004qg-Am for hipsec@ietf.org; Tue, 26 Jun 2007 13:01:42 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3EPo-0000ll-2Q for hipsec@ietf.org; Tue, 26 Jun 2007 13:01:42 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Jun 2007 10:01:19 -0700 X-IronPort-AV: i="4.16,464,1175497200"; d="scan'208"; a="172397114:sNHT203032485" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5QH1HtJ026097; Tue, 26 Jun 2007 10:01:17 -0700 Received: from dwingwxp (sjc-vpn6-185.cisco.com [10.21.120.185]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l5QH1Hvv023441; Tue, 26 Jun 2007 17:01:17 GMT From: "Dan Wing" To: "'HIP WG'" Date: Tue, 26 Jun 2007 10:01:16 -0700 Message-ID: <045f01c7b813$9cbfbf90$b978150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <3CD53916-01B8-4DDE-9780-B1C32E94637E@nomadiclab.com> Thread-Index: Ace31N154026b0uwT/6387OHxzK08gAMtjbA DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5458; t=1182877277; x=1183741277; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20HIP-NAT=20and=20ICE=3A=20moving=20forward |Sender:=20; bh=7wT35+48/kiuRd+fnPdi0PPO0/YdNrW4VmCm5DRWrOs=; b=cf+l76u9CcWgWMqU/IF03/ZEebODJXZnhaPIcPZqb7NW08UOSYDSXdGXLE+c0Atqp73RnRlO fGj0mS/baJdqOONXSFU5pAK7dEN/8zsdjlhzTs0y/OqKZgbJCAqWBCVK; Authentication-Results: sj-dkim-3; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'Hannes Tschofenig' Subject: [Hipsec] HIP-NAT and ICE: moving forward X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org I was asked by several people to point out what deficiencies I saw in hip-nat-traversal-02-pre6 that caused Hannes and I to write an alternate approach: * ICE works in all NAT situations; some of this functionality I didn't see in hip-nat-traversal-02-pre6. ONE EXAMPLE of something I didn't see is what ICE calls a 'triggered check'; this is necessary so that you can traverse a 'Symmetric NAT' without a relay. The only occurrence of the word 'trigger' was in the Connectivity Tests section (in 02-pre6), but it referred to sending the connectivity checks towards the relay (rather than to the peer's Locator address). This won't be helpful with 'Symmetric NATs', and will cause a relay to be used when it could have been avoided. Relays cost someone money to operate, reduce overall availability, and increase jitter and delay. It has long been the design consideration with ICE that relays are always to be avoided. Does hip-nat-traversal-02-pre6 share that design consideration, or is there a different design consideration? (Removing this design requirement would simplify procedures somewhat, at the expense of going through relays. The latest figures from Google indicate 10% of their ICE traffic is going through relays. This might translate into 20% of NATs used by their subscribers are Symmetric NAT, which would mean 20% of the time you will relay traffic. With the additional triggered check procedure, you'll reduce that by half.) (Below I provide a suggestion for how hip-nat-traversal-02-pre6 might show how it maps to ICE.) * ICE was designed designed to be backwards-compatible with non-ICE-aware endpoints. Likewise, I expect that hip-nat-traversal-02-pre6 needs to work with HIP endpoints that do not implement draft-ietf-hip-nat-traversal. Is that accurate? If so, we need to ensure that hip-nat-traversal-02-pre6 works well in such a situation where there won't be connectivity checks performed by the remote peer. I haven't found where hip-nat-traversal-02-pre6 discusses this situation. * I consider it necessary that ESP avoid UDP encapsulation where possible, and not force UDP encapsulation because a HIP host is behind a NAT. This can be accomplished, if there is consensus and interest in doing this. Is there consensus that doing ESP-over-UDP is always okay, especially when both HIP hosts are behind the same NAT (consider an enterprise, where all of their hosts are behind a NAT but those hosts routinely communicate with each other, throw in some 802.11 and T1s and other bandwidth-constrained links)? Currently, hip-nat-traversal-02-pre6 does not attempt to detect if UDP encapsulation can be avoided. * It's difficult to determine how hip-nat-traversal-02-pre6 diverges from ICE, and thus difficult to understand if it will be as successful as ICE in handling various weird NATs and various network topologies. As I recently posted on the BEHAVE mailing list, ICE is used by Yahoo, Google Chat, AOL, and MSN for their peer-to-peer voice chat between users of their respective networks. This is millions of endpoints and, I would guess, hundreds of thousands of successful peer-to-peer connections per day. I know there is a lot of "ICE is for voice" and "ICE is for SIP" religion. Google Chat uses XMPP (Jabber), not SIP. Because hip-nat-traversal-02-pre6 is re-inventing parts of ICE, it would be helpful if it showed how it does ICE's steps -- or that hip-nat-traversal-02-pre6 decided they were unnecessary. The steps of ICE are described in section 2 of the ICE specification: 2.1. Gathering Candidate Addresses 2.2. Connectivity Checks 2.3. Sorting Candidates 2.4. Frozen Candidates 2.5. Security for Checks 2.6. Concluding ICE 2.7. Lite Implementations For HIP, the outline would be something more like: - Gathering Locator Addresses - Connectivity Checks - Sorting Candidates (choosing ESP-over-IP instead of ESP-over-UDP, for example) - Frozen Candidates (probably not necessary for HIP -- I don't think HIP needs to establish multiple HIP connections at the same time between two HIP hosts, does it????) - Security for Checks (HITs) - Concluding HIP Connection Establishment - Lite Implementations (HIP hosts that aren't behind a NAT) * I have noticed some terminology collision around 'middlebox', 'rendezvous server', and 'relay server'. We need to resolve these collisions to continue intelligent and respectful exchange of ideas amongst IETF members. I will begin by explaining that in SIP and in ICE, 'rendezvous server' is where both peers can exchange control messages -- that is where they can "get together". In SIP, such servers are SIP proxies. Rendezvous servers do not ever forward anything but SIP between the two endpoints. In ICE, a 'relay' is controlled by one endpoint and forwards UDP packets to/from that endpoint to/from its peer. The protocol that defines this control mechanism is draft-ietf-behave-turn-03.txt ("TURN"). -d _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 17:42:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Io3-0005D7-Ng; Tue, 26 Jun 2007 17:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Io2-00057w-7R for hipsec@ietf.org; Tue, 26 Jun 2007 17:42:38 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3In4-00066L-01 for hipsec@ietf.org; Tue, 26 Jun 2007 17:42:38 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5251A2CF9; Wed, 27 Jun 2007 00:41:37 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id B454A2C5D; Wed, 27 Jun 2007 00:41:32 +0300 (EEST) Date: Wed, 27 Jun 2007 00:41:32 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Martin Stiemerling Subject: Re: [Hipsec] Rebuilding ICE In-Reply-To: <3D4C521F-8586-4B49-A32B-6BE8D42A18BF@netlab.nec.de> Message-ID: References: <467FAE6D.1070807@gmx.net> <4680C323.2030709@gmx.net> <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> <3D4C521F-8586-4B49-A32B-6BE8D42A18BF@netlab.nec.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 26 Jun 2007, Martin Stiemerling wrote: > Hi all, > > I think that the discussion slipped off the actually topic a bit. The main > questions are basically: > 1. the current HIP NAT traversal draft (draft-ietf-hip-nat-traversal-01) > 2. using ICE and HIP in one way or the other > > For 1: > There is some disagreement between the authors of the draft on how to > continue with the draft as the WG approved approach > (draft-ietf-hip-nat-traversal-01) and the current approach in the upcoming > draft are fundamental different. We have asked the chairs about their opinion > on this but have not received any answer. > IMHO I do not like the approach taken right now on rebuilding ICE and > something different. I do like much more the simple approach take in > draft-ietf-hip-nat-traversal-01 as we need to get a start on HIP's NAT > traversal. There is one severe, technical problem with draft-ietf-hip-nat-traversal-01. It is supposed to work with legacy NATs, but it does not really work with all legacy NATs. The approach requires that there are no p2p-unfriendly NATs between the hosts. Think about the challenging (common?) case where both peers are behind two NATs, one for ISP and one for the ADSL... which totals four NATs. Just one of them needs to be p2p-unfriendly and the NAT traversal fails There is no way in to fallback to full HIP+ESP relay in the draft. There are some other, minor problems with the draft that related to the optimization, like choosing optimal paths for multihomable hosts and properly detecting when the hosts are behind the same NAT. This is the reasoning why we had a look at ICE because it seemed to solve these problems in a better way. I don't see how the draft-ietf-hip-nat-traversal-01 approach can move forwards without introducing relay support somehow. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 17:43:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Iob-00067V-3k; Tue, 26 Jun 2007 17:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3IoZ-00067P-Pq for hipsec@ietf.org; Tue, 26 Jun 2007 17:43:11 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Ini-0006p6-At for hipsec@ietf.org; Tue, 26 Jun 2007 17:43:11 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id DC0382CEB; Wed, 27 Jun 2007 00:42:17 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 44B652C5D; Wed, 27 Jun 2007 00:42:13 +0300 (EEST) Date: Wed, 27 Jun 2007 00:42:13 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Lars Eggert Subject: Re: AW: [Hipsec] Rebuilding ICE In-Reply-To: <8B8969AC-3F60-4B2E-8D27-20C520DBF32D@nokia.com> Message-ID: References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC2F6@MCHP7IDA.ww002.siemens.net> <8B8969AC-3F60-4B2E-8D27-20C520DBF32D@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: HIP WG , Hannes Tschofenig , "ext Tschofenig, Hannes" , Marcus Brunner X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 26 Jun 2007, Lars Eggert wrote: Hi Lars, > I'm still catching up on this thread, but in several email messages I've read > so far, Miika has acknowledged that the idea of adopting ICE concepts for HIP > NAT traversal originated with Phillip. The acknowledgment section of his > draft also credits Phillip. > > To me, this looks like the editor of the WG document is giving credit where > credit is due, on behalf of the working group. there have been also other people included in the ICE discussions, such as Andrey McGregor and Tim Sheppard. There has not been any WG sessions lately where to promote the ideas on the mike, so it has been carried in private and public email conversions. I guess the whole discussion started publicly on the mailing lists already in March by Gonzalo, so I wonder why there was not feedback earlier: http://www1.ietf.org/mail-archive/web/hipsec/current/msg01969.html -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 18:28:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3JWi-0004HQ-CS; Tue, 26 Jun 2007 18:28:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3JWf-0004F3-MD for hipsec@ietf.org; Tue, 26 Jun 2007 18:28:46 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3JVd-0000Xn-4v for hipsec@ietf.org; Tue, 26 Jun 2007 18:28:45 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 9AD052C58; Wed, 27 Jun 2007 01:27:40 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id B70BC2C55; Wed, 27 Jun 2007 01:27:35 +0300 (EEST) Date: Wed, 27 Jun 2007 01:27:35 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing Subject: Re: [Hipsec] HIP-NAT and ICE: moving forward In-Reply-To: <045f01c7b813$9cbfbf90$b978150a@amer.cisco.com> Message-ID: References: <045f01c7b813$9cbfbf90$b978150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: 'HIP WG' , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 26 Jun 2007, Dan Wing wrote: Hi Dan and others, you can find an updated version of the document from here: http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre7.txt I have updated the document based on comments from various people. Quick summary: * Rewrote the base exchange section (LOCATOR already in I2) * Rewrote connectivity tests to look more like ICE * The above two bullet points affected mobility which I updated also * Added an ICE-to-HIP translation dictionary to the appendix > I was asked by several people to point out what deficiencies I saw > in hip-nat-traversal-02-pre6 that caused Hannes and I to write an > alternate approach: > > * ICE works in all NAT situations; some of this functionality I didn't > see in hip-nat-traversal-02-pre6. > > ONE EXAMPLE of something I didn't see is what ICE calls a 'triggered > check'; this is necessary so that you can traverse a 'Symmetric NAT' > without a relay. The only occurrence of the word 'trigger' was in > the Connectivity Tests section (in 02-pre6), but it referred to > sending the connectivity checks towards the relay (rather than to > the peer's Locator address). This won't be helpful with 'Symmetric > NATs', and will cause a relay to be used when it could have been > avoided. Relays cost someone money to operate, reduce overall > availability, and increase jitter and delay. It has long been the > design consideration with ICE that relays are always to be avoided. > Does hip-nat-traversal-02-pre6 share that design consideration, or > is there a different design consideration? > > (Removing this design requirement would simplify procedures > somewhat, at the expense of going through relays. The latest > figures from Google indicate 10% of their ICE traffic is going > through relays. This might translate into 20% of NATs used by their > subscribers are Symmetric NAT, which would mean 20% of the time you > will relay traffic. With the additional triggered check procedure, > you'll reduce that by half.) Added to ICE dictionary. See also section 3.5. Connectivity Tests and the return routability tests, which can be used as triggered checks. > (Below I provide a suggestion for how hip-nat-traversal-02-pre6 > might show how it maps to ICE.) > > * ICE was designed designed to be backwards-compatible with > non-ICE-aware endpoints. Likewise, I expect that > hip-nat-traversal-02-pre6 needs to work with HIP endpoints that do > not implement draft-ietf-hip-nat-traversal. Is that accurate? If > so, we need to ensure that hip-nat-traversal-02-pre6 works well in > such a situation where there won't be connectivity checks performed > by the remote peer. I haven't found where hip-nat-traversal-02-pre6 > discusses this situation. Good point. I guess the thing would be to detect unsupported types of locators (type 3 which contains the port + address) and to skip processing of them. Would this do for you? > * I consider it necessary that ESP avoid UDP encapsulation where > possible, and not force UDP encapsulation because a HIP host is > behind a NAT. This can be accomplished, if there is consensus and > interest in doing this. Is there consensus that doing ESP-over-UDP > is always okay, especially when both HIP hosts are behind the same > NAT (consider an enterprise, where all of their hosts are behind a > NAT but those hosts routinely communicate with each other, throw in > some 802.11 and T1s and other bandwidth-constrained links)? > Currently, hip-nat-traversal-02-pre6 does not attempt to detect > if UDP encapsulation can be avoided. I guess this does the trick: 3.5. Connectivity Tests UPDATE packets destined to the unreflexive locators are sent directly over IP. UPDATE packets destined for reflexive peer, relay and leased locators are sent transport layer encapsulated. > * It's difficult to determine how hip-nat-traversal-02-pre6 diverges > from ICE, and thus difficult to understand if it will be as > successful as ICE in handling various weird NATs and various > network topologies. As I recently posted on the BEHAVE mailing > list, ICE is used by Yahoo, Google Chat, AOL, and MSN for their > peer-to-peer voice chat between users of their respective > networks. This is millions of endpoints and, I would guess, > hundreds of thousands of successful peer-to-peer connections > per day. I know there is a lot of "ICE is for voice" and > "ICE is for SIP" religion. Google Chat uses XMPP (Jabber), > not SIP. > > Because hip-nat-traversal-02-pre6 is re-inventing parts of > ICE, it would be helpful if it showed how it does ICE's steps > -- or that hip-nat-traversal-02-pre6 decided they were > unnecessary. The steps of ICE are described in section 2 > of the ICE specification: See Appendix A. Differences to ICE > For HIP, the outline would be something more like: > > - Gathering Locator Addresses > - Connectivity Checks > - Sorting Candidates (choosing ESP-over-IP instead > of ESP-over-UDP, for example) > - Frozen Candidates (probably not necessary for > HIP -- I don't think HIP needs > to establish multiple HIP > connections at the same time > between two HIP hosts, does > it????) > - Security for Checks (HITs) > - Concluding HIP Connection Establishment > - Lite Implementations (HIP hosts that aren't > behind a NAT) Mimicing the ICE structure would make it readable to ICE folks. However, we are standardizing this work (at least for now) at the HIP WG. Therefore, I have preferred a more HIP oriented view on the contents. Due to my time constraints, it is currently oriented towards people who have developed and read base exchange, mobility and rvs drafts. I hope that it could be more standalone in the following versions. > * I have noticed some terminology collision around 'middlebox', > 'rendezvous server', and 'relay server'. We need to resolve these > collisions to continue intelligent and respectful exchange of > ideas amongst IETF members. There is a ICE-to-HIP termilogy in the appendix since there seemed to be a need for it. Please suggest changes if you have some better terms. As I said before, the current standardization forum is HIP, and we don't have to cling to ICE terminology. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 26 20:59:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Lsj-0007eO-Is; Tue, 26 Jun 2007 20:59:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Lsh-0007eI-QQ for hipsec@ietf.org; Tue, 26 Jun 2007 20:59:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Kch-00079R-KV for hipsec@ietf.org; Tue, 26 Jun 2007 19:39:19 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 26 Jun 2007 16:24:05 -0700 X-IronPort-AV: i="unknown"; a="172640542:sNHT0" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5QNO56t017367; Tue, 26 Jun 2007 16:24:05 -0700 Received: from dwingwxp ([10.21.87.141]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5QNO4GW024771; Tue, 26 Jun 2007 23:24:04 GMT From: "Dan Wing" To: "'Miika Komu'" Subject: RE: [Hipsec] HIP-NAT and ICE: moving forward Date: Tue, 26 Jun 2007 16:24:04 -0700 Message-ID: <069601c7b849$161b26b0$b978150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Ace4QTl512pLV25XT9apLwlv/+gszQABFzNw DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10521; t=1182900245; x=1183764245; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Hipsec]=20HIP-NAT=20and=20ICE=3A=20moving=20forward |Sender:=20; bh=onYQRiV7EVr+he3IizniFJXFmDZeVe8t/tHXWXnwzXo=; b=p6n930uonzGf5rZMIIG8hIqpsDWa38JJGKo3JdmaIv/3crzWl5z25TFsuzf7h0PbrVlyEZXG 8J2PzxT32tiQwcsPChpiOQY0AIX3CxG7gFgeNz615IWgQbK8vIC1JMvUNBAbCl4oXBNcADW50R j0E9B/fI5ZEhi59wy3UwZNiDw=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: 'HIP WG' , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > Hi Dan and others, > > you can find an updated version of the document from here: > > http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre7.txt > > I have updated the document based on comments from various > people. Quick > summary: > > * Rewrote the base exchange section (LOCATOR already in I2) > * Rewrote connectivity tests to look more like ICE > * The above two bullet points affected mobility which I updated also > * Added an ICE-to-HIP translation dictionary to the appendix Thanks. Sorry for the extra work, but I do think this will help with eventual IETF last call and certainly helps the ICE Camp people, as I guess we have been labeled. I'll read that revision on Wednesday. > > I was asked by several people to point out what deficiencies I saw > > in hip-nat-traversal-02-pre6 that caused Hannes and I to write an > > alternate approach: > > > > * ICE works in all NAT situations; some of this > functionality I didn't > > see in hip-nat-traversal-02-pre6. > > > > ONE EXAMPLE of something I didn't see is what ICE calls a > 'triggered > > check'; this is necessary so that you can traverse a > 'Symmetric NAT' > > without a relay. The only occurrence of the word 'trigger' was in > > the Connectivity Tests section (in 02-pre6), but it referred to > > sending the connectivity checks towards the relay (rather than to > > the peer's Locator address). This won't be helpful with 'Symmetric > > NATs', and will cause a relay to be used when it could have been > > avoided. Relays cost someone money to operate, reduce overall > > availability, and increase jitter and delay. It has long been the > > design consideration with ICE that relays are always to be avoided. > > Does hip-nat-traversal-02-pre6 share that design consideration, or > > is there a different design consideration? > > > > (Removing this design requirement would simplify procedures > > somewhat, at the expense of going through relays. The latest > > figures from Google indicate 10% of their ICE traffic is going > > through relays. This might translate into 20% of NATs > used by their > > subscribers are Symmetric NAT, which would mean 20% of the time you > > will relay traffic. With the additional triggered check procedure, > > you'll reduce that by half.) > > Added to ICE dictionary. See also section 3.5. Connectivity > Tests and the return routability tests, which can be used as > triggered checks. Thanks. > > (Below I provide a suggestion for how hip-nat-traversal-02-pre6 > > might show how it maps to ICE.) > > > > * ICE was designed designed to be backwards-compatible with > > non-ICE-aware endpoints. Likewise, I expect that > > hip-nat-traversal-02-pre6 needs to work with HIP endpoints that do > > not implement draft-ietf-hip-nat-traversal. Is that accurate? If > > so, we need to ensure that hip-nat-traversal-02-pre6 works well in > > such a situation where there won't be connectivity checks performed > > by the remote peer. I haven't found where > hip-nat-traversal-02-pre6 > > discusses this situation. > > Good point. I guess the thing would be to detect unsupported types of > locators (type 3 which contains the port + address) and to > skip processing of them. Would this do for you? What ICE does for its backwards-compatibility is place the most-likely- to-work transport address into the field that every endpoint understands (even non-ICE endpoints). It's my understanding that HIP endpoints don't have to understand or support HIP-over-UDP at all; is that accurate? If so, I agree that having them quietly ignore Locators they can't use seems what those hip-nat-traversal-unaware HIP hosts will need to do. Furthermore, it will be important for a hip-nat-traversal-aware HIP host to be sure to provide a Locator that is a "pure" HIP locator (without UDP encapsulation), through a HIP relay of some sort (which can convert HIP-over-IP to HIP-over-UDP). Someone will have to pay for the costs of running and operating that relay, of course. A hip-nat-traversal-aware HIP host, when initiating a connection to another HIP host will always need to do that, because unfortunately it cannot know, a priori, if the remote HIP host is hip-nat-traversal-aware or not. Nor can it know if the remote HIP host is, right now, behind a HIP-unaware NAT, a HIP-aware NAT, or has a publicly-routable IP address. > > * I consider it necessary that ESP avoid UDP encapsulation where > > possible, and not force UDP encapsulation because a HIP host is > > behind a NAT. This can be accomplished, if there is consensus and > > interest in doing this. Is there consensus that doing ESP-over-UDP > > is always okay, especially when both HIP hosts are behind the same > > NAT (consider an enterprise, where all of their hosts are behind a > > NAT but those hosts routinely communicate with each other, throw in > > some 802.11 and T1s and other bandwidth-constrained links)? > > Currently, hip-nat-traversal-02-pre6 does not attempt to detect > > if UDP encapsulation can be avoided. > > I guess this does the trick: > > 3.5. Connectivity Tests > > UPDATE packets destined to the unreflexive locators are sent directly > over IP. UPDATE packets destined for reflexive peer, relay and > leased locators are sent transport layer encapsulated. That requires any packet that traverses a NAT to be UDP-encapsulated. There are many NATs which don't require UDP encapsulation for ESP traffic. I'm at a hotel right now, and I can establish a plain IPsec connection from behind their NAT, and my Linksys WRT54G also supports IPsec connections. Another thing which I'm not clear on from -pre6 was this case, where there are two hosts that want to communicate, and they are both behind their own legacy NATs, and there are adjacent hosts with the intended peer's IP address. Here is an example. In the following diagram, host-a wants to communicate with host-d: +---------Internet---------------+ | | NAT-1 NAT-2 | | +-------+-------+ +------+----+ | | | | host-a host-b host-c host-d 192.168.1.1 192.168.1.128 192.168.1.1 192.168.1.128 They will exchange each others unreflexive locators (that is, their local IP addresses), and they'll do connectivity checks with each other -- those connectivity checks need to fail when they communicate with their adjacent host (that is, when host-a does a connectivity check with host-b, we want to know that host-b is _NOT_ the desired endpoint). We want the connection to be established with host-c. I expect this is clearer in -pre7, but I won't have time to read it until tomorrow. > > * It's difficult to determine how hip-nat-traversal-02-pre6 diverges > > from ICE, and thus difficult to understand if it will be as > > successful as ICE in handling various weird NATs and various > > network topologies. As I recently posted on the BEHAVE mailing > > list, ICE is used by Yahoo, Google Chat, AOL, and MSN for their > > peer-to-peer voice chat between users of their respective > > networks. This is millions of endpoints and, I would guess, > > hundreds of thousands of successful peer-to-peer connections > > per day. I know there is a lot of "ICE is for voice" and > > "ICE is for SIP" religion. Google Chat uses XMPP (Jabber), > > not SIP. > > > > Because hip-nat-traversal-02-pre6 is re-inventing parts of > > ICE, it would be helpful if it showed how it does ICE's steps > > -- or that hip-nat-traversal-02-pre6 decided they were > > unnecessary. The steps of ICE are described in section 2 > > of the ICE specification: > > See Appendix A. Differences to ICE Thanks. > > For HIP, the outline would be something more like: > > > > - Gathering Locator Addresses > > - Connectivity Checks > > - Sorting Candidates (choosing ESP-over-IP instead > > of ESP-over-UDP, for example) > > - Frozen Candidates (probably not necessary for > > HIP -- I don't think HIP needs > > to establish multiple HIP > > connections at the same time > > between two HIP hosts, does > > it????) > > - Security for Checks (HITs) > > - Concluding HIP Connection Establishment > > - Lite Implementations (HIP hosts that aren't > > behind a NAT) > > Mimicing the ICE structure would make it readable to ICE > folks. However, > we are standardizing this work (at least for now) at the HIP WG. > Therefore, I have preferred a more HIP oriented view on the > contents. Due > to my time constraints, it is currently oriented towards > people who have > developed and read base exchange, mobility and rvs drafts. I > hope that it > could be more standalone in the following versions. While it may appear that I am only participating to cause some sort of mischief, I am participating to ensure that the years of effort that went into developing ICE will help HIP's legacy NAT traversal be successful. > > * I have noticed some terminology collision around 'middlebox', > > 'rendezvous server', and 'relay server'. We need to resolve these > > collisions to continue intelligent and respectful exchange of > > ideas amongst IETF members. > > There is a ICE-to-HIP termilogy in the appendix since there > seemed to be a > need for it. Please suggest changes if you have some better > terms. As I > said before, the current standardization forum is HIP, and we > don't have to cling to ICE terminology. Yes, I clearly understand that the HIP working group is not the MMUSIC working group. Please understand that my efforts in the HIP working group are voluntary. My intent is to ensure a well-functioning legacy NAT traversal for HIP. I believe that is your intent, as well. Let us please all work together on our mutual common interest. Thanks for your quick revision of the WG document; my apologies that I will not have time to review it until tomorrow. -d _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 27 07:23:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Vcl-00042u-Ab; Wed, 27 Jun 2007 07:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Vck-00042m-L7 for hipsec@ietf.org; Wed, 27 Jun 2007 07:23:50 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Vbo-0007NB-HI for hipsec@ietf.org; Wed, 27 Jun 2007 07:23:50 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id BEE3A2CD2; Wed, 27 Jun 2007 14:22:47 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id EDE0E2CDA; Wed, 27 Jun 2007 14:22:42 +0300 (EEST) Date: Wed, 27 Jun 2007 14:22:42 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing Subject: RE: [Hipsec] HIP-NAT and ICE: moving forward In-Reply-To: <069601c7b849$161b26b0$b978150a@amer.cisco.com> Message-ID: References: <069601c7b849$161b26b0$b978150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: 'HIP WG' , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 26 Jun 2007, Dan Wing wrote: >> Good point. I guess the thing would be to detect unsupported types of >> locators (type 3 which contains the port + address) and to >> skip processing of them. Would this do for you? > > What ICE does for its backwards-compatibility is place the most-likely- > to-work transport address into the field that every endpoint understands > (even non-ICE endpoints). > > It's my understanding that HIP endpoints don't have to understand or > support HIP-over-UDP at all; is that accurate? Yes, from standardization point of view. However, I know that the three well-known implementations are already using UDP encapsulation for client-side NAT traversal, but this has not really been standardized. > If so, I agree that having them quietly ignore Locators they can't use > seems what those hip-nat-traversal-unaware HIP hosts will need to do. > Furthermore, it will be important for a hip-nat-traversal-aware HIP host > to be sure to provide a Locator that is a "pure" HIP locator (without > UDP encapsulation), through a HIP relay of some sort (which can convert > HIP-over-IP to HIP-over-UDP). The relay in the current draft does not support conversion from IP to UDP and vice versa because it would have handle fragmentation issues also. However, this could be a nice feature in the following versions of the draft in addition to IPv4-IPv6 conversion... We can do conversion in the relay quite automatically if we would require connectivity checks also when registering to a relay. This way, the client would establish IPv4, IPv6 or UDPv4 connectivity with the relay. Anyway, this requires a little more though, especially on how it reacts with mobility. > Someone will have to pay for the costs of running and operating that > relay, of course. Yes, the fragmentation, transport layer conversion and IP address conversion definitely involve a computational cost. Maybe this could provided with new registration values, but I don't know if they would just complicate things and maybe require a new locator type for registered locator, I am not sure yet. > A hip-nat-traversal-aware HIP host, when initiating a connection to > another HIP host will always need to do that, because unfortunately it > cannot know, a priori, if the remote HIP host is hip-nat-traversal-aware > or not. Nor can it know if the remote HIP host is, right now, behind a > HIP-unaware NAT, a HIP-aware NAT, or has a publicly-routable IP address. These things can be detected using the connectivity tests. >> 3.5. Connectivity Tests >> >> UPDATE packets destined to the unreflexive locators are sent directly >> over IP. UPDATE packets destined for reflexive peer, relay and >> leased locators are sent transport layer encapsulated. > > That requires any packet that traverses a NAT to be UDP-encapsulated. > There are many NATs which don't require UDP encapsulation for ESP > traffic. I'm at a hotel right now, and I can establish a plain > IPsec connection from behind their NAT, and my Linksys WRT54G also > supports IPsec connections. Are you proposing a scheme where HIP traffic is UDP encapsulated, but IPsec is not? I have thought about this before, but I thought that the benefits would be smaller than the drawbacks on extra protocol handling. > Another thing which I'm not clear on from -pre6 was this case, > where there are two hosts that want to communicate, and they are > both behind their own legacy NATs, and there are adjacent > hosts with the intended peer's IP address. > > Here is an example. In the following diagram, host-a wants to > communicate with host-d: > > +---------Internet---------------+ > | | > NAT-1 NAT-2 > | | > +-------+-------+ +------+----+ > | | | | > host-a host-b host-c host-d > 192.168.1.1 192.168.1.128 192.168.1.1 192.168.1.128 > > > They will exchange each others unreflexive locators (that is, > their local IP addresses), and they'll do connectivity checks > with each other -- those connectivity checks need to fail when > they communicate with their adjacent host (that is, when host-a > does a connectivity check with host-b, we want to know that > host-b is _NOT_ the desired endpoint). We want the connection > to be established with host-c. > > I expect this is clearer in -pre7, but I won't have time to read > it until tomorrow. I think this requires an extra statement somewhere that the host-b will just drop the I1 packet because of the HIT belongs to host-c. This is where the naming and security of HIP fits nicely in.. Another statement should be added about opportunistic mode. In opportunistic mode, the destination HIT in I1 is NULL. Host-b would answer to host-a even though this was not the intended purpose. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 28 02:53:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3nsS-0007qS-G7; Thu, 28 Jun 2007 02:53:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3nsR-0007hB-9C for hipsec@ietf.org; Thu, 28 Jun 2007 02:53:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ns0-0005Xj-0z for hipsec@ietf.org; Thu, 28 Jun 2007 02:53:15 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 27 Jun 2007 23:52:46 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOb3gkarR7PEh2dsb2JhbACPJgIJDiw X-IronPort-AV: i="4.16,469,1175497200"; d="scan'208"; a="382316290:sNHT26853140" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5S6qkRp030760; Wed, 27 Jun 2007 23:52:46 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5S6qjXH028185; Thu, 28 Jun 2007 06:52:45 GMT From: "Dan Wing" To: "'Miika Komu'" , "'Martin Stiemerling'" Subject: RE: [Hipsec] Rebuilding ICE Date: Wed, 27 Jun 2007 23:52:45 -0700 Message-ID: <05f401c7b950$eef20870$dd93150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ace4Ou71btnrogfWR3eYi2b1pYsmVQBFW8mg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2783; t=1183013566; x=1183877566; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Hipsec]=20Rebuilding=20ICE |Sender:=20; bh=QV8wOJPntOIVqvcluw9rxT4S038PWoUHuq2LgU/xBlY=; b=BUwlemTCoaHseHnThV2ixKlTlDyvpb4shHU3+9hBjKOIEJEM2tgq0UN1Y9B9rWAWfSo6HEJC j3+EClXm/0Du09lvvZKCRLpLlHOzZ1mX0D/hH8XHqNdYa8g7WZN7zAD7; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: 'HIP WG' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi] > Sent: Tuesday, June 26, 2007 2:42 PM > To: Martin Stiemerling > Cc: HIP WG > Subject: Re: [Hipsec] Rebuilding ICE > > On Tue, 26 Jun 2007, Martin Stiemerling wrote: > > > Hi all, > > > > I think that the discussion slipped off the actually topic > a bit. The main > > questions are basically: > > 1. the current HIP NAT traversal draft > (draft-ietf-hip-nat-traversal-01) > > 2. using ICE and HIP in one way or the other > > > > For 1: > > There is some disagreement between the authors of the draft > on how to > > continue with the draft as the WG approved approach > > (draft-ietf-hip-nat-traversal-01) and the current approach > in the upcoming > > draft are fundamental different. We have asked the chairs > about their opinion > > on this but have not received any answer. > > IMHO I do not like the approach taken right now on > rebuilding ICE and > > something different. I do like much more the simple > approach take in > > draft-ietf-hip-nat-traversal-01 as we need to get a start > on HIP's NAT > > traversal. > > There is one severe, technical problem with > draft-ietf-hip-nat-traversal-01. It is supposed to work with > legacy NATs, > but it does not really work with all legacy NATs. The > approach requires > that there are no p2p-unfriendly NATs between the hosts. > Think about the > challenging (common?) case where both peers are behind two > NATs, one for > ISP and one for the ADSL... which totals four NATs. Just one > of them needs > to be p2p-unfriendly and the NAT traversal fails There is no > way in to fallback to full HIP+ESP relay in the draft. Actually, _both_ need to be behind p2p-unfriendly NATs before a HIP and ESP relay is necessary -- if ietf-hip-nat- traversal-02pre does triggered checks. (This is what I was referring to in an earlier message about the 10% Google number.) > There are some other, minor problems with the draft that > related to the > optimization, like choosing optimal paths for multihomable > hosts and properly detecting when the hosts are behind the same NAT. > > This is the reasoning why we had a look at ICE because it > seemed to solve > these problems in a better way. I don't see how the > draft-ietf-hip-nat-traversal-01 approach can move forwards without > introducing relay support somehow. Unless you discard the case of both users behind p2p-unfriendly NATs, I agree. -d > -- > Miika Komu > http://www.iki.fi/miika/ > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 28 07:37:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3sJp-00063c-Di; Thu, 28 Jun 2007 07:37:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3sJl-0005wm-OK for hipsec@ietf.org; Thu, 28 Jun 2007 07:37:45 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3sIx-0001AS-Ta for hipsec@ietf.org; Thu, 28 Jun 2007 07:37:45 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 0EFF62CBE; Thu, 28 Jun 2007 14:36:54 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 336622C96; Thu, 28 Jun 2007 14:36:47 +0300 (EEST) Date: Thu, 28 Jun 2007 14:36:47 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Dan Wing Subject: RE: [Hipsec] HIP-NAT and ICE: moving forward In-Reply-To: Message-ID: References: <069601c7b849$161b26b0$b978150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'HIP WG' , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Wed, 27 Jun 2007, Miika Komu wrote: >> If so, I agree that having them quietly ignore Locators they can't use >> seems what those hip-nat-traversal-unaware HIP hosts will need to do. >> Furthermore, it will be important for a hip-nat-traversal-aware HIP host to >> be sure to provide a Locator that is a "pure" HIP locator (without UDP >> encapsulation), through a HIP relay of some sort (which can convert >> HIP-over-IP to HIP-over-UDP). > > The relay in the current draft does not support conversion from IP to UDP and > vice versa because it would have handle fragmentation issues also. However, > this could be a nice feature in the following versions of the draft in > addition to IPv4-IPv6 conversion... > > We can do conversion in the relay quite automatically if we would require > connectivity checks also when registering to a relay. This way, the client > would establish IPv4, IPv6 or UDPv4 connectivity with the relay. Anyway, this > requires a little more though, especially on how it reacts with > mobility. > >> Someone will have to pay for the costs of running and operating that relay, >> of course. > > Yes, the fragmentation, transport layer conversion and IP address conversion > definitely involve a computational cost. Maybe this could provided with new > registration values, but I don't know if they would just complicate things > and maybe require a new locator type for registered locator, I am not sure > yet. Replying to my own question here: I think the most modular approach to the fragmentation etc issues is to allow the Relay to select how many locators it will include. If the relay includes only IP address(es) with UDP port(s), the reachability tests cannot select a plain IPv4 or IPv6 address and the relay does not have to care about fragmentation etc. If the relay includes also plain IPv4 or IPv6 address, it has to be able to deal with fragmentation, address family conversion and UDP (de)tunneling issues. Will be added for the next version unless there are other comments. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 28 09:30:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3u52-00010f-42; Thu, 28 Jun 2007 09:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3u50-00010U-6N for hipsec@ietf.org; Thu, 28 Jun 2007 09:30:38 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3u4a-0003C2-Nr for hipsec@ietf.org; Thu, 28 Jun 2007 09:30:38 -0400 Received: from vicinn.wightman.ca ([216.110.238.10] helo=[192.168.0.197]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I3u4a-0000Kc-06; Thu, 28 Jun 2007 09:30:12 -0400 In-Reply-To: <8B8969AC-3F60-4B2E-8D27-20C520DBF32D@nokia.com> References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC2F6@MCHP7IDA.ww002.siemens.net> <8B8969AC-3F60-4B2E-8D27-20C520DBF32D@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: AW: [Hipsec] Rebuilding ICE Date: Thu, 28 Jun 2007 09:30:11 -0400 To: Lars Eggert X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - vicinn.wightman.ca ([192.168.0.197]) [216.110.238.10] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: HIP WG , Hannes Tschofenig , Marcus Brunner X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 26-Jun-07, at 10:56 , Lars Eggert wrote: > On 2007-6-26, at 10:03, ext Tschofenig, Hannes wrote: >> Thanks to Phillip Matthews and Dan Wing who actually pointed the >> group to ICE. Without them there would not be a single line in the >> current WG NAT traversal draft. >> >> Instead of being thankful that the group receives input from other >> groups in the IETF a few individuals swiched to the panic mode. > > I'm still catching up on this thread, but in several email messages > I've read so far, Miika has acknowledged that the idea of adopting > ICE concepts for HIP NAT traversal originated with Phillip. The > acknowledgment section of his draft also credits Phillip. > > To me, this looks like the editor of the WG document is giving > credit where credit is due, on behalf of the working group. For the record, I want to say that I don't think my work in bringing ICE to the attention of the HIP community was that big a deal -- I am sure that someone else would have pointed that out if I hadn't. In fact, it probably would not have happened if Miika had not attended the P2PSIP WG meeting in Prague and mentioned HIP and his document. What struck me when talking with Miika afterwords is how HIP and P2PSIP were going down similar paths. P2PSIP (because of its participants' familiarity with MMUSIC's work on ICE) seem to have a better NAT traversal story, while HIP had a better story in other places. This is what lead to draft-matthews-p2psip-hip-hop-00. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 28 09:43:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3uGy-0002ck-PW; Thu, 28 Jun 2007 09:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3uGy-0002cf-3c for hipsec@ietf.org; Thu, 28 Jun 2007 09:43:00 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3uGr-0006mZ-4V for hipsec@ietf.org; Thu, 28 Jun 2007 09:43:00 -0400 Received: from vicinn.wightman.ca ([216.110.238.10] helo=[192.168.0.197]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I3uGy-0005w4-FY; Thu, 28 Jun 2007 09:43:00 -0400 In-Reply-To: References: <467FAE6D.1070807@gmx.net> <4680C323.2030709@gmx.net> <8B38D701-1C69-4987-B5C2-798CFB03F286@indranet.co.nz> <3D4C521F-8586-4B49-A32B-6BE8D42A18BF@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Rebuilding ICE Date: Thu, 28 Jun 2007 09:42:52 -0400 To: Martin Stiemerling X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - vicinn.wightman.ca ([192.168.0.197]) [216.110.238.10] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: HIP WG X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 26-Jun-07, at 17:41 , Miika Komu wrote: > On Tue, 26 Jun 2007, Martin Stiemerling wrote: > >> Hi all, >> >> I think that the discussion slipped off the actually topic a bit. >> The main questions are basically: >> 1. the current HIP NAT traversal draft (draft-ietf-hip-nat- >> traversal-01) >> 2. using ICE and HIP in one way or the other >> >> For 1: >> There is some disagreement between the authors of the draft on how >> to continue with the draft as the WG approved approach (draft-ietf- >> hip-nat-traversal-01) and the current approach in the upcoming >> draft are fundamental different. We have asked the chairs about >> their opinion on this but have not received any answer. >> IMHO I do not like the approach taken right now on rebuilding ICE >> and something different. I do like much more the simple approach >> take in draft-ietf-hip-nat-traversal-01 as we need to get a start >> on HIP's NAT traversal. > > There is one severe, technical problem with draft-ietf-hip-nat- > traversal-01. It is supposed to work with legacy NATs, but it does > not really work with all legacy NATs. The approach requires that > there are no p2p-unfriendly NATs between the hosts. Think about the > challenging (common?) case where both peers are behind two NATs, > one for ISP and one for the ADSL... which totals four NATs. Just > one of them needs to be p2p-unfriendly and the NAT traversal fails > There is no way in to fallback to full HIP+ESP relay in the draft. > > There are some other, minor problems with the draft that related to > the optimization, like choosing optimal paths for multihomable > hosts and properly detecting when the hosts are behind the same NAT. > > This is the reasoning why we had a look at ICE because it seemed to > solve these problems in a better way. I don't see how the draft- > ietf-hip-nat-traversal-01 approach can move forwards without > introducing relay support somehow. I would like to point out one other problem with the approach in draft-ietf-hip-nat-traversal-01. That approach used STUN only. Dan and I are currently working with Jonathan Rosenberg on revising the STUN specification. Unless we are overruled by the BEHAVE working group (which I do not expect), the final version of the revised STUN specification will strongly caution against that approach, except for those very specific cases where that approach is OK. I think it is pretty clear that HIP is NOT one of those situations, so I think there might be some difficulty in getting the approach of draft-ietf- hip-nat-traversal-01 through the IESG. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 28 14:21:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ycI-00063Y-To; Thu, 28 Jun 2007 14:21:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ycI-00063S-7a for hipsec@ietf.org; Thu, 28 Jun 2007 14:21:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3ybl-0006gN-1x for hipsec@ietf.org; Thu, 28 Jun 2007 14:21:18 -0400 Received: (qmail invoked by alias); 28 Jun 2007 18:14:01 -0000 Received: from p5498490E.dip.t-dialin.net (EHLO [192.168.1.2]) [84.152.73.14] by mail.gmx.net (mp029) with SMTP; 28 Jun 2007 20:14:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19+SzQrHFB+M8KyxYSnWoVq7LeavKtR2EMFxwUgpb VXJwvzqi5RiS1Q Message-ID: <4683FA66.3000306@gmx.net> Date: Thu, 28 Jun 2007 20:13:58 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Marcus Brunner Subject: Re: AW: [Hipsec] Rebuilding ICE References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC34B@MCHP7IDA.ww002.siemens.net> <251E0BEF-97CA-41C6-BCBC-1DC3156109D4@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: HIP WG , "Tschofenig, Hannes" X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Marcus, which parts of ICE do you consider an overkill? Ciao Hannes Marcus Brunner wrote: > Pekka, > > Well put. I agree with you statement. > > Some parts of the ICE methodoldy are a bit an overkill in my opinion, so they could be discussed, whether they apply to HIP. The benefit naturally is that people seam to understand ICE. > > Actually, I would even propose that we should have a look at node-multi-homing, becasue it seams there are similarities like offered IP addresses/ports/.. to the responding peer. > > > Kind regards, > > Marcus > > --------------------------------------------------- > > Dr. Marcus Brunner > NEC Laboratories Europe > Network Division > > NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > > >> -----Original Message----- >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] >> Sent: Tuesday, June 26, 2007 11:26 AM >> To: Tschofenig, Hannes >> Cc: HIP WG; Hannes Tschofenig; Marcus Brunner >> Subject: Re: AW: [Hipsec] Rebuilding ICE >> >> Hannes, >> >> >>> ICE is a methodology. We suggest to make extensive use of it. >>> The only "format" the ICE document suggests is the encoding of >>> candiates. >>> I have stated many times that one can think about a more optimized >>> encoding. That's OK. >>> >> I think we all understand the basic idea of ICE being a >> methodology. >> At least I am not objecting to using it, as a methodology. >> However, in addition to defining the SDP encoding for the >> candidates, it also defines how to use STUN and TURN, so >> there are, indirectly, more formats and network nodes (TURN >> and STUN servers) built into ICE. >> >> Now, from my point of view an important architectural is not >> to make HIP dependent on TURN and STUN servers, nor the UDP >> encapsulation formats used in STUN, nor any other such details. >> >> HIP has already the rendezvous servers defined, and a >> well-defined mechanism for contacting hosts using the >> rendezvous servers. It also already has a mobility >> mechanism, and a rudimentary mechanism for multi-homing. >> >> I may have misunderstood, but from my point of view, using >> ICE terminology, HIP already seems to have the necessary >> mechanisms form Encoding, Offering and Answering, and >> Completing (I'm drawing these terms from the ICE tutorial, my >> apology if the spec uses other terms). >> >> What HIP is primarily missing is Gathering and Prioritising, >> which BTW are not a real protocol issues, and therefore most >> probably could be quite easily adopted from ICE, and >> Checking, where the past idea was to use the SHIM6 protoocol. >> For checking, the fact that native HIP uses both a separate >> protocol number of HIP control and ESP (or something else) >> for data traffic necessitates the ICE checking methodology to >> be modified anyway. The same applies, as far as I can see, >> also to the NAT traversal case, where HIP is using the IPsec >> encoding of UDP, not generic UDP. Hence, I don't think STUN >> applies there directly. >> >> Remember, when HIP is used the UDP and TCP messages are >> carried encoded somehow, typically in ESP wrappers, and >> therefore some of the problems specific to ICE/STUN (like >> port reuse) don't apply or apply in a different form. >> >> >>>> It's also fairly clear that there is reason to somewhat adapt ICE >>>> anyway; >>>> >>> That's fine. For example, I wrote that you could use the RVS as a >>> reverse tunneling mechanism (in the spirit of TURN) to avoid using >>> TURN. In an upcoming draft I will explain why it still >>> >> makes a lot of >> >>> sense to use TURN but that's another story. >>> >> For TURN I don't understand why it would make any sense to >> use it, but maybe I don't understand it, again. Anyway, I >> would consider it undesirable to make HIP dependent on TURN. >> >> If you would like to allow *optional* use of TURN, them I'm >> fine. As long as the base HIP mechanisms would work with >> only one new piece of infrastructure, the RVS servers. >> >> But I really would like to hear your detailed list of issues >> on the table. >> >> --Pekka >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> >> _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 29 03:09:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Abw-0000X1-Fy; Fri, 29 Jun 2007 03:09:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3yWI-0002iE-3s for hipsec@ietf.org; Thu, 28 Jun 2007 14:15:06 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3yTZ-00045R-BA for hipsec@ietf.org; Thu, 28 Jun 2007 14:12:17 -0400 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 88262200F03F; Thu, 28 Jun 2007 20:12:08 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0H89J7ewSSy; Thu, 28 Jun 2007 20:12:08 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6390F2000178; Thu, 28 Jun 2007 20:11:48 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Hipsec] Rebuilding ICE Date: Thu, 28 Jun 2007 20:13:09 +0200 Message-ID: In-Reply-To: <251E0BEF-97CA-41C6-BCBC-1DC3156109D4@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Hipsec] Rebuilding ICE Thread-Index: Ace31Gkq8yQ44J3pQr+vJLcPxcbBLgA07T9g References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC34B@MCHP7IDA.ww002.siemens.net> <251E0BEF-97CA-41C6-BCBC-1DC3156109D4@nomadiclab.com> From: "Marcus Brunner" To: "Pekka Nikander" , "Tschofenig, Hannes" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-Mailman-Approved-At: Fri, 29 Jun 2007 03:09:43 -0400 Cc: HIP WG , Hannes Tschofenig X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Pekka, Well put. I agree with you statement.=20 Some parts of the ICE methodoldy are a bit an overkill in my opinion, so = they could be discussed, whether they apply to HIP. The benefit = naturally is that people seam to understand ICE. Actually, I would even propose that we should have a look at = node-multi-homing, becasue it seams there are similarities like offered = IP addresses/ports/.. to the responding peer. Kind regards, Marcus --------------------------------------------------- Dr. Marcus Brunner NEC Laboratories Europe Network Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England 2832014 =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Tuesday, June 26, 2007 11:26 AM > To: Tschofenig, Hannes > Cc: HIP WG; Hannes Tschofenig; Marcus Brunner > Subject: Re: AW: [Hipsec] Rebuilding ICE >=20 > Hannes, >=20 > > ICE is a methodology. We suggest to make extensive use of it. > > The only "format" the ICE document suggests is the encoding of=20 > > candiates. > > I have stated many times that one can think about a more optimized=20 > > encoding. That's OK. >=20 > I think we all understand the basic idea of ICE being a=20 > methodology. =20 > At least I am not objecting to using it, as a methodology. =20 > However, in addition to defining the SDP encoding for the=20 > candidates, it also defines how to use STUN and TURN, so=20 > there are, indirectly, more formats and network nodes (TURN=20 > and STUN servers) built into ICE. >=20 > Now, from my point of view an important architectural is not=20 > to make HIP dependent on TURN and STUN servers, nor the UDP=20 > encapsulation formats used in STUN, nor any other such details. >=20 > HIP has already the rendezvous servers defined, and a=20 > well-defined mechanism for contacting hosts using the=20 > rendezvous servers. It also already has a mobility=20 > mechanism, and a rudimentary mechanism for multi-homing. >=20 > I may have misunderstood, but from my point of view, using=20 > ICE terminology, HIP already seems to have the necessary=20 > mechanisms form Encoding, Offering and Answering, and=20 > Completing (I'm drawing these terms from the ICE tutorial, my=20 > apology if the spec uses other terms). >=20 > What HIP is primarily missing is Gathering and Prioritising,=20 > which BTW are not a real protocol issues, and therefore most=20 > probably could be quite easily adopted from ICE, and=20 > Checking, where the past idea was to use the SHIM6 protoocol.=20 > For checking, the fact that native HIP uses both a separate=20 > protocol number of HIP control and ESP (or something else)=20 > for data traffic necessitates the ICE checking methodology to=20 > be modified anyway. The same applies, as far as I can see,=20 > also to the NAT traversal case, where HIP is using the IPsec=20 > encoding of UDP, not generic UDP. Hence, I don't think STUN=20 > applies there directly. >=20 > Remember, when HIP is used the UDP and TCP messages are=20 > carried encoded somehow, typically in ESP wrappers, and=20 > therefore some of the problems specific to ICE/STUN (like=20 > port reuse) don't apply or apply in a different form. >=20 > >> It's also fairly clear that there is reason to somewhat adapt ICE=20 > >> anyway; > > > > That's fine. For example, I wrote that you could use the RVS as a=20 > > reverse tunneling mechanism (in the spirit of TURN) to avoid using=20 > > TURN. In an upcoming draft I will explain why it still=20 > makes a lot of=20 > > sense to use TURN but that's another story. >=20 > For TURN I don't understand why it would make any sense to=20 > use it, but maybe I don't understand it, again. Anyway, I=20 > would consider it undesirable to make HIP dependent on TURN. >=20 > If you would like to allow *optional* use of TURN, them I'm=20 > fine. As long as the base HIP mechanisms would work with=20 > only one new piece of infrastructure, the RVS servers. >=20 > But I really would like to hear your detailed list of issues=20 > on the table. >=20 > --Pekka >=20 >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 29 03:34:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4B0A-0005g4-AY; Fri, 29 Jun 2007 03:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4B08-0005fu-Tj for hipsec@ietf.org; Fri, 29 Jun 2007 03:34:44 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4B08-0001UZ-7T for hipsec@ietf.org; Fri, 29 Jun 2007 03:34:44 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l5T7YTrp026490; Fri, 29 Jun 2007 10:34:29 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l5T7YTQd026487; Fri, 29 Jun 2007 10:34:29 +0300 Date: Fri, 29 Jun 2007 10:34:29 +0300 (EEST) From: Pekka Savola To: Marcus Brunner In-Reply-To: Message-ID: References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC34B@MCHP7IDA.ww002.siemens.net> <251E0BEF-97CA-41C6-BCBC-1DC3156109D4@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.3/3550/Fri Jun 29 03:35:13 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: HIP WG , Hannes Tschofenig , "Tschofenig, Hannes" Subject: [Hipsec] Every protocol in the IETF needs its own NAT traversal mechanism X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Thu, 28 Jun 2007, Marcus Brunner wrote: > Well put. I agree with you statement. > > Some parts of the ICE methodoldy are a bit an overkill in my > opinion, so they could be discussed, whether they apply to HIP. The > benefit naturally is that people seam to understand ICE. > > Actually, I would even propose that we should have a look at > node-multi-homing, becasue it seams there are similarities like > offered IP addresses/ports/.. to the responding peer. Not speaking to rebuilding ICE.. but even earlier (let's say about 1.5-2 years ago, on this list) I recall commenting that HIP NAT traversal work would be non-trivial and would end up reinventing Teredo. It's disturbing that most protocols seem to have a need to rebuild their own NAT traversal mechanisms, but the IETF doesn't seem very good at tackling these kinds of issues. I was suggesting that BEHAVE WG would be unnecessary if we just focused on IPv6 and IPv6-over-NAT transition mechanisms but that didn't seem to gain traction.. >> -----Original Message----- >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] >> Sent: Tuesday, June 26, 2007 11:26 AM >> To: Tschofenig, Hannes >> Cc: HIP WG; Hannes Tschofenig; Marcus Brunner >> Subject: Re: AW: [Hipsec] Rebuilding ICE >> >> Hannes, >> >>> ICE is a methodology. We suggest to make extensive use of it. >>> The only "format" the ICE document suggests is the encoding of >>> candiates. >>> I have stated many times that one can think about a more optimized >>> encoding. That's OK. >> >> I think we all understand the basic idea of ICE being a >> methodology. >> At least I am not objecting to using it, as a methodology. >> However, in addition to defining the SDP encoding for the >> candidates, it also defines how to use STUN and TURN, so >> there are, indirectly, more formats and network nodes (TURN >> and STUN servers) built into ICE. >> >> Now, from my point of view an important architectural is not >> to make HIP dependent on TURN and STUN servers, nor the UDP >> encapsulation formats used in STUN, nor any other such details. >> >> HIP has already the rendezvous servers defined, and a >> well-defined mechanism for contacting hosts using the >> rendezvous servers. It also already has a mobility >> mechanism, and a rudimentary mechanism for multi-homing. >> >> I may have misunderstood, but from my point of view, using >> ICE terminology, HIP already seems to have the necessary >> mechanisms form Encoding, Offering and Answering, and >> Completing (I'm drawing these terms from the ICE tutorial, my >> apology if the spec uses other terms). >> >> What HIP is primarily missing is Gathering and Prioritising, >> which BTW are not a real protocol issues, and therefore most >> probably could be quite easily adopted from ICE, and >> Checking, where the past idea was to use the SHIM6 protoocol. >> For checking, the fact that native HIP uses both a separate >> protocol number of HIP control and ESP (or something else) >> for data traffic necessitates the ICE checking methodology to >> be modified anyway. The same applies, as far as I can see, >> also to the NAT traversal case, where HIP is using the IPsec >> encoding of UDP, not generic UDP. Hence, I don't think STUN >> applies there directly. >> >> Remember, when HIP is used the UDP and TCP messages are >> carried encoded somehow, typically in ESP wrappers, and >> therefore some of the problems specific to ICE/STUN (like >> port reuse) don't apply or apply in a different form. >> >>>> It's also fairly clear that there is reason to somewhat adapt ICE >>>> anyway; >>> >>> That's fine. For example, I wrote that you could use the RVS as a >>> reverse tunneling mechanism (in the spirit of TURN) to avoid using >>> TURN. In an upcoming draft I will explain why it still >> makes a lot of >>> sense to use TURN but that's another story. >> >> For TURN I don't understand why it would make any sense to >> use it, but maybe I don't understand it, again. Anyway, I >> would consider it undesirable to make HIP dependent on TURN. >> >> If you would like to allow *optional* use of TURN, them I'm >> fine. As long as the base HIP mechanisms would work with >> only one new piece of infrastructure, the RVS servers. >> >> But I really would like to hear your detailed list of issues >> on the table. >> >> --Pekka >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 29 12:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Jga-0003vA-C2; Fri, 29 Jun 2007 12:51:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JgZ-0003sL-2g for hipsec@ietf.org; Fri, 29 Jun 2007 12:51:07 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4JgI-00005l-EX for hipsec@ietf.org; Fri, 29 Jun 2007 12:51:07 -0400 Received: from 74-51-33-189.telnetcommunications.com ([74.51.33.189]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I4JgH-0003vq-0V; Fri, 29 Jun 2007 12:50:50 -0400 In-Reply-To: <069601c7b849$161b26b0$b978150a@amer.cisco.com> References: <069601c7b849$161b26b0$b978150a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <525A8569-1B2E-459C-A9EA-B2617ACAAD33@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] HIP-NAT and ICE: moving forward Date: Fri, 29 Jun 2007 12:36:27 -0400 To: Dan Wing X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - 74-51-33-189.telnetcommunications.com [74.51.33.189] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'HIP WG' , 'Hannes Tschofenig' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 26-Jun-07, at 19:24 , Dan Wing wrote: >>> >>> * ICE was designed designed to be backwards-compatible with >>> non-ICE-aware endpoints. Likewise, I expect that >>> hip-nat-traversal-02-pre6 needs to work with HIP endpoints that do >>> not implement draft-ietf-hip-nat-traversal. Is that accurate? If >>> so, we need to ensure that hip-nat-traversal-02-pre6 works well in >>> such a situation where there won't be connectivity checks performed >>> by the remote peer. I haven't found where >> hip-nat-traversal-02-pre6 >>> discusses this situation. >> >> Good point. I guess the thing would be to detect unsupported types of >> locators (type 3 which contains the port + address) and to >> skip processing of them. Would this do for you? > > What ICE does for its backwards-compatibility is place the most- > likely- > to-work transport address into the field that every endpoint > understands > (even non-ICE endpoints). > > It's my understanding that HIP endpoints don't have to understand or > support HIP-over-UDP at all; is that accurate? If so, I agree that > having them quietly ignore Locators they can't use seems what those > hip-nat-traversal-unaware HIP hosts will need to do. Wouldn't this be a change from the way ICE works today? Right now, both endpoints have to agree on the list of checks to perform and the order they are going to do them in. I am not sure this is a fatal flaw: I suspect that the introduction of Controlling/Controlled endpoints into ICE has substantially decreased the importance of doing checks in the same order. However, we would need to think about this carefully. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 29 12:51:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Jgi-0004Hn-Mg; Fri, 29 Jun 2007 12:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Jgh-0004GQ-O9 for hipsec@ietf.org; Fri, 29 Jun 2007 12:51:15 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4JgN-00006C-00 for hipsec@ietf.org; Fri, 29 Jun 2007 12:51:15 -0400 Received: from 74-51-33-189.telnetcommunications.com ([74.51.33.189]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I4JgL-0003vq-2f; Fri, 29 Jun 2007 12:50:54 -0400 In-Reply-To: References: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC34B@MCHP7IDA.ww002.siemens.net> <251E0BEF-97CA-41C6-BCBC-1DC3156109D4@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C75FEAC-C746-49B2-95C5-48DB0BFB70FA@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [Hipsec] Every protocol in the IETF needs its own NAT traversal mechanism Date: Fri, 29 Jun 2007 12:47:19 -0400 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - 74-51-33-189.telnetcommunications.com [74.51.33.189] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "Tschofenig, Hannes" , HIP WG , Hannes Tschofenig , Marcus Brunner X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On 29-Jun-07, at 03:34 , Pekka Savola wrote: > > Not speaking to rebuilding ICE.. but even earlier (let's say about > 1.5-2 years ago, on this list) I recall commenting that HIP NAT > traversal work would be non-trivial and would end up reinventing > Teredo. > > It's disturbing that most protocols seem to have a need to rebuild > their own NAT traversal mechanisms, but the IETF doesn't seem very > good at tackling these kinds of issues. I was suggesting that > BEHAVE WG would be unnecessary if we just focused on IPv6 and IPv6- > over-NAT transition mechanisms but that didn't seem to gain traction.. Isn't this exactly the problem that we are trying to solve with NAT traversal for HIP?? If all protocols ran over HIP, and if we solve the NAT traversal for HIP problem, then application protocols do not need to worry about NAT traversal. This is one of the arguments made for using HIP for P2P overlays given in draft-matthews-p2psip-hip-hop-00. - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 29 19:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Q1s-00054E-84; Fri, 29 Jun 2007 19:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Q1r-00053M-2z for hipsec@ietf.org; Fri, 29 Jun 2007 19:37:31 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Q1h-00080M-F5 for hipsec@ietf.org; Fri, 29 Jun 2007 19:37:31 -0400 Received: from 74-51-33-143.telnetcommunications.com ([74.51.33.143]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I4Q1o-00063F-Cw; Fri, 29 Jun 2007 19:37:29 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Fri, 29 Jun 2007 17:19:42 -0400 To: Miika Komu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - 74-51-33-143.telnetcommunications.com [74.51.33.143] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: HIP WG Subject: [Hipsec] Comment on draft-ietf-hip-nat-traversal-02-pre7: No controlling/controllled endpoints X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Miika: In -02-pre7 it says: The conclusion of the connectivity checks, i.e., selection of the final address pair, differs the most as a result of fitting the ICE nomination algorithm to HIP mobility mechanisms. There is no "controlling agent" even though it is the Initiator who triggers the connectivity tests by sending an UPDATE containing a LOCATOR parameter through the relay. As there is no controlling agent, the end-hosts make a local decision on which locator pair to choose. This could lead to asymmetric address pairs, but the priority algorithm guarantees that the address pairs converge. I am curious to know more why you think the concept of Controlling vs. Controlled endpoints can be eliminated. For those new to ICE, one endpoint is selected as the Controlling endpoint and the other becomes the Controlled endpoint. The Controlling endpoint is the one that makes the final section of the transmission path. This feature was added to ICE recently for the following reasons: a) It allows the Controlling endpoint to do extra, unspecified, tests to select a transmission path. One example is to do RTT tests to select the path with the lowest delay. With the concept of a Controlling endpoint, there is no need to standardize these tests. b) It gives ICE a high degree of future-proofing. Since the Controlling endpoint makes the final selection, it can decide based on its own criteria, which may be different than the other end which is running a different ICE version. Do you think these properties are not useful in ICE-for-HIP? Or is there some other way to achieve them? - Philip _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 29 22:05:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4SL4-0002wf-T3; Fri, 29 Jun 2007 22:05:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4SL3-0002wQ-Hx for hipsec@ietf.org; Fri, 29 Jun 2007 22:05:29 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4SKP-0000KS-CV for hipsec@ietf.org; Fri, 29 Jun 2007 22:05:29 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKF006M2F2I61@szxga01-in.huawei.com> for hipsec@ietf.org; Sat, 30 Jun 2007 10:03:55 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKF00749F2I4D@szxga01-in.huawei.com> for hipsec@ietf.org; Sat, 30 Jun 2007 10:03:54 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKF005D5F2EPW@szxml04-in.huawei.com> for hipsec@ietf.org; Sat, 30 Jun 2007 10:03:54 +0800 (CST) Date: Sat, 30 Jun 2007 10:03:50 +0800 From: JiangXingFeng Subject: RE: [Hipsec] Every protocol in the IETF needs its own NAT traversalmechanism In-reply-to: <7C75FEAC-C746-49B2-95C5-48DB0BFB70FA@magma.ca> To: 'Philip Matthews' , 'Pekka Savola' Message-id: <001201c7baba$e7761f30$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace6bbVYGeQWaC+YTSyHfXZ1icgu6wATLRGw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'HIP WG' , 'Hannes Tschofenig' , "'Tschofenig, Hannes'" , 'Marcus Brunner' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, : Solving NAT traversal issues at relative lower level protocol is a good option, so that applications riding on this protocol could not care about the existence of the NAT. HIP may be a choice to do this work. Regards! -- Jiang XingFeng > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Saturday, June 30, 2007 12:47 AM > To: Pekka Savola > Cc: Tschofenig, Hannes; HIP WG; Hannes Tschofenig; Marcus Brunner > Subject: Re: [Hipsec] Every protocol in the IETF needs its own NAT > traversalmechanism > > > On 29-Jun-07, at 03:34 , Pekka Savola wrote: > > > > > Not speaking to rebuilding ICE.. but even earlier (let's say about > > 1.5-2 years ago, on this list) I recall commenting that HIP NAT > > traversal work would be non-trivial and would end up reinventing > > Teredo. > > > > It's disturbing that most protocols seem to have a need to rebuild > > their own NAT traversal mechanisms, but the IETF doesn't seem very > > good at tackling these kinds of issues. I was suggesting that > > BEHAVE WG would be unnecessary if we just focused on IPv6 and IPv6- > > over-NAT transition mechanisms but that didn't seem to gain traction.. > > Isn't this exactly the problem that we are trying to solve with NAT > traversal for HIP?? > > If all protocols ran over HIP, and if we solve the NAT traversal for > HIP problem, then application protocols do not need to worry about > NAT traversal. > > This is one of the arguments made for using HIP for P2P overlays > given in draft-matthews-p2psip-hip-hop-00. > > - Philip > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 30 04:33:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4YO2-0004pN-1x; Sat, 30 Jun 2007 04:32:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4YO0-0004pG-VO for hipsec@ietf.org; Sat, 30 Jun 2007 04:32:56 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4YNw-0003Z9-Bi for hipsec@ietf.org; Sat, 30 Jun 2007 04:32:56 -0400 Received: (qmail 12227 invoked by uid 0); 30 Jun 2007 08:32:51 -0000 Received: from 90.186.174.46 by www153.gmx.net with HTTP; Sat, 30 Jun 2007 10:32:51 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Sat, 30 Jun 2007 10:32:51 +0200 From: "Hannes Tschofenig" In-Reply-To: <001201c7baba$e7761f30$6905a40a@china.huawei.com> Message-ID: <20070630083251.32030@gmx.net> MIME-Version: 1.0 References: <001201c7baba$e7761f30$6905a40a@china.huawei.com> Subject: Re: RE: [Hipsec] Every protocol in the IETF needs its own NAT traversalmechanism To: JiangXingFeng , pekkas@netcore.fi, philip_matthews@magma.ca X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19Jhecf7phJ1fYJKiik7u4Z7yxwSlq6DxT9+9DLBB VVckMd3n+MUsmDB71RmQ9AaYmA/9x80NL/eA== Content-Transfer-Encoding: 7bit X-GMX-UID: UnntLspZTlI8UJsGtWlrzRBOU2poZZnT X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: hannes.tschofenig@nsn.com, Brunner@netlab.nec.de, hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Jiang, I guess you misunderstood Pekka's comment a bit. He says that a number of protocols need to provide support for NAT traversal. He seems to believe that there is a potential for re-use. You still need to provide NAT traversal support on the higher layers because you cannot assume lower layers to offer the support since there is no universal deployment for any of the lower layer protocols. P2P filesharing and gaming environments have the largest deployment from a NAT traversal support. They just use existing libraries that use very similar techniques as ICE (since that's the area where the ideas for ICE came from). I would be able to play any of my favorite games in case they would have waited for HIP, MIP etc. to come up with a lower layer mechanism ... Technically speaking there is also a difference between the NAT traversal support at the lower layer and at higher layers because lower layers don't have a "flow" semantic. That is also the reason why we didn't see how to make use of the frozen candidates with ICE when applying them to HIP and MIP (but maybe we just need to think a bit more about it). Ciao Hannes -------- Original-Nachricht -------- Datum: Sat, 30 Jun 2007 10:03:50 +0800 Von: JiangXingFeng An: \'Philip Matthews\' , \'Pekka Savola\' CC: \'HIP WG\' , \'Hannes Tschofenig\' , "\'Tschofenig, Hannes\'" , \'Marcus Brunner\' Betreff: RE: [Hipsec] Every protocol in the IETF needs its own NAT traversalmechanism > Hi, : > > Solving NAT traversal issues at relative lower level protocol is a good > option, so that applications riding on this protocol could not care about > the existence of the NAT. > > HIP may be a choice to do this work. > > Regards! > -- > Jiang XingFeng > > > > -----Original Message----- > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Sent: Saturday, June 30, 2007 12:47 AM > > To: Pekka Savola > > Cc: Tschofenig, Hannes; HIP WG; Hannes Tschofenig; Marcus Brunner > > Subject: Re: [Hipsec] Every protocol in the IETF needs its own NAT > > traversalmechanism > > > > > > On 29-Jun-07, at 03:34 , Pekka Savola wrote: > > > > > > > > Not speaking to rebuilding ICE.. but even earlier (let's say about > > > 1.5-2 years ago, on this list) I recall commenting that HIP NAT > > > traversal work would be non-trivial and would end up reinventing > > > Teredo. > > > > > > It's disturbing that most protocols seem to have a need to rebuild > > > their own NAT traversal mechanisms, but the IETF doesn't seem very > > > good at tackling these kinds of issues. I was suggesting that > > > BEHAVE WG would be unnecessary if we just focused on IPv6 and IPv6- > > > over-NAT transition mechanisms but that didn't seem to gain traction.. > > > > Isn't this exactly the problem that we are trying to solve with NAT > > traversal for HIP?? > > > > If all protocols ran over HIP, and if we solve the NAT traversal for > > HIP problem, then application protocols do not need to worry about > > NAT traversal. > > > > This is one of the arguments made for using HIP for P2P overlays > > given in draft-matthews-p2psip-hip-hop-00. > > > > - Philip > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec > > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 30 11:43:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4f6m-0006Ve-DP; Sat, 30 Jun 2007 11:43:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4f6k-0006VX-NQ for hipsec@ietf.org; Sat, 30 Jun 2007 11:43:34 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4f6D-00062F-OJ for hipsec@ietf.org; Sat, 30 Jun 2007 11:43:34 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id BDBE72CC0; Sat, 30 Jun 2007 18:42:56 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 18BD32CB6; Sat, 30 Jun 2007 18:42:56 +0300 (EEST) Date: Sat, 30 Jun 2007 18:42:56 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Philip Matthews In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: HIP WG Subject: [Hipsec] Re: Comment on draft-ietf-hip-nat-traversal-02-pre7: No controlling/controllled endpoints X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 29 Jun 2007, Philip Matthews wrote: Hi Philip, > I am curious to know more why you think the concept of Controlling > vs. Controlled endpoints can be eliminated. > > For those new to ICE, one endpoint is selected as the Controlling endpoint > and the other becomes the Controlled endpoint. The Controlling endpoint > is the one that makes the final section of the transmission path. I eliminated this feature because there was conflict in merging HIP and ICE together. I resolved the conflict in favour of HIP mobility mechanisms. According to the current HIP mobility draft, a host selects its own preferred locator independently of the peer. You also mentioned that the Controller concept is not so important anymore because the checks are done in the same order at both sides. > This feature was added to ICE recently for the following reasons: > a) It allows the Controlling endpoint to do extra, unspecified, tests to > select a transmission path. One example is to do RTT tests to select the > path with the lowest delay. With the concept of a Controlling endpoint, > there is no need to standardize these tests. There is nothing that prevents the peers of doing extra RTT tests separately from each other. If a host prefers, it can use another locator with smaller RTT when its connectivity was successfully tested. It may result in asymmetric paths, but they are not strictly forbidden by the mobility draft. > b) It gives ICE a high degree of future-proofing. Since the Controlling > endpoint makes the final selection, it can decide based on its own criteria, > which may be different than the other end which is running a different > ICE version. Is the Controller always the host with the higher ICE version? > Do you think these properties are not useful in ICE-for-HIP? Or is there > some other way to achieve them? Currently the draft specifies that the preferred bit should be always zero for transport locators. Maybe it was too quick decision. I think we can achieve roughly the same functionality by doing an additional handover after the connectivity tests (that include RTT measurements). In the additional handover, we can set the preferred bit up for the locator with the best RTT. This would prioritize the locator to the highest numeric value, 127. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 30 12:26:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4fmh-00028K-Qo; Sat, 30 Jun 2007 12:26:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4fmh-00028E-8e for hipsec@ietf.org; Sat, 30 Jun 2007 12:26:55 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4fmg-0006FC-VC for hipsec@ietf.org; Sat, 30 Jun 2007 12:26:55 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id F09442CCD; Sat, 30 Jun 2007 19:26:24 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070504 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070504 X-Spam-Niksula: No Received: from kekkonen (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 712A42CB5; Sat, 30 Jun 2007 19:26:24 +0300 (EEST) Date: Sat, 30 Jun 2007 19:26:24 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Hannes Tschofenig Subject: Re: RE: [Hipsec] Every protocol in the IETF needs its own NAT traversalmechanism In-Reply-To: <20070630083251.32030@gmx.net> Message-ID: References: <001201c7baba$e7761f30$6905a40a@china.huawei.com> <20070630083251.32030@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: hipsec@ietf.org, Brunner@netlab.nec.de, hannes.tschofenig@nsn.com, Philip Matthews X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Sat, 30 Jun 2007, Hannes Tschofenig wrote: Hi Hannes, > You still need to provide NAT traversal support on the higher layers > because you cannot assume lower layers to offer the support since there > is no universal deployment for any of the lower layer protocols. I agree that there it would be nice that have libraries for applications doing NAT-traversal, and better yet, a standardized interface for it. However, deploying such a library will have even more difficult deployment hurdle than HIP, because it requires that the application using it will be modified. > P2P filesharing and gaming environments have the largest deployment from > a NAT traversal support. They just use existing libraries that use very > similar techniques as ICE (since that's the area where the ideas for ICE > came from). I would be able to play any of my favorite games in case > they would have waited for HIP, MIP etc. to come up with a lower layer > mechanism ... The problem is that there are too many "hacks" around to get around NATs. Some of them work better than others. I believe this is one of the main reasons for standardizing ICE (and now, HIP-ICE). Also, I think it is quite possible that a game vendor could bundle its product along with a HIP-ICE implementation. This would bring additional benefits in terms of global end-to-end addressing and autenticating paying customers with public-key cryptography... -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec