From mkomu@niksula.hut.fi Mon Aug 4 03:34:00 2003 From: mkomu@niksula.hut.fi (Miika Komu) Date: Mon Aug 4 02:34:00 2003 Subject: [Hipsec] Brief update of HIP activitities at Vienna In-Reply-To: <3F20D354.4070601@nomadiclab.com> Message-ID: On Fri, 25 Jul 2003, Pekka Nikander wrote: > I was too busy to much talk to the other implementors, and > hence I don't know what happened on the implementation front. > Maybe other's can fill in the details there. I have been away for two weeks and I haven't been able to read my email. Anyway, here's a summary of the debugging activies in the IETF: Less people were present than earlier: Andrew, Mika, Krisu and me. HIPL expected to continue from where we were left in SF because base exchange was working just fine in San Francisco. This expectation was not met due to a couple of reasons. Implementations were not 100 % up-to-date with the latest draft. Andrew could not test readdressing with HIPL because he has to do some time-consuming refactoring before readdressing can be supported in his implementation. Base exchange was established in both ways after a quite small amount of debugging in the terminal room. The new cookie mechanism worked perfectly on the first try in both of the implementations. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ From rgm@htt-consult.com Mon Aug 4 08:46:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Mon Aug 4 07:46:01 2003 Subject: [Hipsec] Who is? Message-ID: <5.1.0.14.2.20030804080626.03200640@localhost> jh@lohi.eng.song.fi This email was bouncing messages so mailman disabled it.... From swb@employees.org Mon Aug 4 08:50:01 2003 From: swb@employees.org (Scott W Brim) Date: Mon Aug 4 07:50:01 2003 Subject: [Hipsec] Who is? In-Reply-To: <5.1.0.14.2.20030804080626.03200640@localhost>; from rgm@htt-consult.com on Mon, Aug 04, 2003 at 08:07:02AM -0400 References: <5.1.0.14.2.20030804080626.03200640@localhost> Message-ID: <20030804081105.Z1928@sbrim-w2k01> On Mon, Aug 04, 2003 08:07:02AM -0400, Robert Moskowitz allegedly wrote: > jh@lohi.eng.song.fi Juha Heinanen. From rgm@htt-consult.com Mon Aug 4 09:03:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Mon Aug 4 08:03:01 2003 Subject: [Hipsec] Who is? In-Reply-To: <20030804081105.Z1928@sbrim-w2k01> References: <5.1.0.14.2.20030804080626.03200640@localhost> <5.1.0.14.2.20030804080626.03200640@localhost> Message-ID: <5.1.0.14.2.20030804082312.030f7110@localhost> At 08:11 AM 8/4/2003 -0400, Scott W Brim wrote: >On Mon, Aug 04, 2003 08:07:02AM -0400, Robert Moskowitz allegedly wrote: > > jh@lohi.eng.song.fi > >Juha Heinanen. If anyone knows him, let him know what's happening.... From thomas.r.henderson@boeing.com Tue Aug 5 15:29:02 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Tue Aug 5 14:29:02 2003 Subject: [Hipsec] cookie hash target no longer needed Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B588F@xch-nw-27.nw.nos.boeing.com> Pekka, With the new cookie procedure, there is no longer any need to send hash = target in the Birthday_Cookie parameter. See below changes to the draft-07. Tom *** draft-moskowitz-hip-07.txt 2003-07-01 18:12:21.000000000 -0700 --- draft-moskowitz-hip-07-bis.txt 2003-08-05 10:14:14.000000000 -0700 *************** *** 664,670 **** concatenation of I, the HITs of the parties, and J, and take a = SHA-1 hash over this concatenation. The lowest order K bits of the = result MUST be zeros. To accomplish this, the Initiator will have to - generate a number of Js until one produces the hash target. The + generate a number of Js until one produces the hash target of zero. = The =20 *************** *** 1373,1393 **** | Random # J or K, 8 bytes = | | = | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Hash Target, 8 bytes = | - | = | - = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Type 2 (in R1) or 3 (in I2) - Length 36 + Length 28 Reserved Zero when sent, ignored when received Birthday System boot counter Random # I random number K or K is the number of verified bits (in R1 packet) Random # J random number (in I2 packet) - Hash Target calculated hash value =20 - Birthday, Random #I, K, Random #J, and Hash Target are in network - byte order. + Birthday, Random #I, K, and Random #J are in network byte order. =20 From rgm@htt-consult.com Fri Aug 8 15:20:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Fri Aug 8 14:20:01 2003 Subject: [Hipsec] Today is the deadline for RSA papers Message-ID: <5.1.0.14.2.20030808144103.02ebe298@localhost> Is anyone submitting a HIP paper there? From pekka.nikander@nomadiclab.com Tue Aug 12 15:56:03 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Aug 12 14:56:03 2003 Subject: [Hipsec] Mumbles about HIP (was Re: apps people?) In-Reply-To: <3F39151E.30202@iprg.nokia.com> References: <3F333E40.6090101@it.su.se> <07af01c3608f$16d6c6b0$70144104@eagleswings> <20030812105112.4a937c31.moore@cs.utk.edu> <3F39151E.30202@iprg.nokia.com> Message-ID: <3F393D71.10605@nomadiclab.com> Fred, Fred Templin wrote: > ... but do you truly have an alternate proposal that > will work for intermittently-connected/disconnected sites, sites that > frequently change provider points of attachment, multi-homed sites, > etc? I asked others the same question and they mumbled something > about HIP but ducked my pointed questions as to how soon we could > expect to see an alternate proposal. As far as I see, HIP does not currently provide anything for intermittently-conneted/disconnnected sites. Perhaps it could, but AFAIK nobody has *seriously* considered that question. (My gut feeling is that if HIP was adopted, the nature of this and many other questions would change quite a lot. But that is just an educated guess, at best.) > .... So, > unless there is some grand solution currently being architected in some > skunkworks project out of the public eye ... (And if there is such a stealth > mode project in the works, I think it high time that it be fully disclosed > to the community in good faith.) I don't know about any skunkwork projects. However, since HIP was mentioned, perhaps I should try to clarify the situation. There was a HIP mailing list for a long time @lists.freeswan.org. However, due to hardware problems the list crashed three times during the last year or so, losing its membership at least once, and the archive at least once, too. (I don't remember the details). Anyway, there is now a new HIP mailing list @honor.trusecure.com, see http://honor.trusecure.com/mailman/listinfo/hipsec We tried to subscribe everybody we knew about to the new mailing list, but I am sure some addresses just got lost. If you are interested, please join to the new mailing list. It is currently very low volume, but may get some traffic fairly soon (see below). However, I don't expect it to get anywhere near IPNG volumes... What comes to the architecture and base protocol specs, they are fairly close to be ready for experimental. On the other hand, serious work on multi-homing, mobility, IPv4 NAT traversal and DNS issues has only recently begun, and requires lots of work before completed. As I mentioned at the multi6 meeting in Vienna, there are currently four interoperating implementations, at least two of which also support limited HIP based mobility. At least one even supports mobility between IPv6 and IPv4. I am not aware of any implementations that would seriously support multi-homing, even though some support for that is in draft-nikander-hip-mm-00.txt There are also some discussions going on with some ADs about the possibility of a working group that would produce experimental RFCs. However, it is not clear whether such a group, if created, should be a working group or an IRTF research group. That is an issue that should be discussed fairly soon at the hipsec ML. --Pekka Nikander From ftemplin@iprg.nokia.com Wed Aug 13 00:16:00 2003 From: ftemplin@iprg.nokia.com (Fred Templin) Date: Tue Aug 12 23:16:00 2003 Subject: [Hipsec] Re: Mumbles about HIP (was Re: apps people?) References: <3F333E40.6090101@it.su.se> <07af01c3608f$16d6c6b0$70144104@eagleswings> <20030812105112.4a937c31.moore@cs.utk.edu> <3F39151E.30202@iprg.nokia.com> <3F393D71.10605@nomadiclab.com> Message-ID: <3F394D7B.1060709@iprg.nokia.com> Pekka Nikander wrote > There was a HIP mailing list for a long time @lists.freeswan.org. > However, due to hardware problems the list crashed three times during > the last year or so, losing its membership at least once, and the > archive at least once, too. (I don't remember the details). Yes, I'm subscribed to that list - since 7/16/2002, actually. There was a pretty healthy amount of traffic between 3/14/03 - 3/26/03 and then it went silent. Since then, I have received two messages - one on 6/29/03 and another on 8/10/03 (only two days ago) - both messages were from you, actually. I never saw any announcement of the new list... > Anyway, there is now a new HIP mailing list @honor.trusecure.com, > see http://honor.trusecure.com/mailman/listinfo/hipsec > We tried to subscribe everybody we knew about to the new mailing > list, but I am sure some addresses just got lost. If you I guess I must have been one of those who just got lost - but isn't it strange I should still be seeing messages on the old list then? > are interested, please join to the new mailing list. It is currently > very low volume, but may get some traffic fairly soon (see below). > However, I don't expect it to get anywhere near IPNG volumes... Gee - maybe *this* is the skunkworks project I have been sensing?! :^} Sure; I'll go ahead and subscribe myself to the new list. Fred ftemplin@iprg.nokia.com From pekka.nikander@nomadiclab.com Wed Aug 13 00:23:01 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Tue Aug 12 23:23:01 2003 Subject: [Hipsec] Re: Mumbles about HIP (was Re: apps people?) In-Reply-To: <3F394D7B.1060709@iprg.nokia.com> References: <3F333E40.6090101@it.su.se> <07af01c3608f$16d6c6b0$70144104@eagleswings> <20030812105112.4a937c31.moore@cs.utk.edu> <3F39151E.30202@iprg.nokia.com> <3F393D71.10605@nomadiclab.com> <3F394D7B.1060709@iprg.nokia.com> Message-ID: <3F39B452.2010401@nomadiclab.com> Fred, Fred Templin wrote: >> There was a HIP mailing list for a long time @lists.freeswan.org. > > Yes, I'm subscribed to that list - since 7/16/2002, actually. There was > a pretty healthy amount of traffic between 3/14/03 - 3/26/03 and then > it went silent. I guess the list crashed at 3/26/03, short shortly thereafter. Your address probably got lost already then, since it did have some more traffic afterwards. Then it crashed again sometime in July, and AFAIK it has not been restored after that. > Since then, I have received two messages - one on 6/29/03 > and another on 8/10/03 (only two days ago) - both messages were from > you, actually. I never saw any announcement of the new list... Those must have been crossposted to some other list. The 8/10/03 message I meant to crosspost to the new list (not the old one), but my fingers made a mistake. The other list the message was crossposted to was multi6. I don't remember about the 6/29/03 one. (I've been spending time with my family all the summer, and reading mail at odd hours without enough of coffee.) We announced the new list on the new list :-) My intention is to annouce it elsewhere, too, but that is just still in my pipeline. --Pekka Nikander From mcr@sandelman.ottawa.on.ca Wed Aug 13 11:34:00 2003 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Wed Aug 13 10:34:00 2003 Subject: [Hipsec] Re: Mumbles about HIP (was Re: apps people?) In-Reply-To: Your message of "Wed, 13 Aug 2003 06:45:22 +0300." <3F39B452.2010401@nomadiclab.com> Message-ID: <26999.1060786570@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- > There was a HIP mailing list for a long time @lists.freeswan.org. @lists.freeswan.org has been having trouble for a long time. A combination of hardware issues, and mailman being able to recover, and eating itself. We have moved all lists to another machine that is running majordomo2. If I should resurrect hipsec@lists.freeswan.org, let me know. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBPzpRiYqHRg3pndX9AQHC4gP9EoOkAMMlA2hYDfwuBBHrcaEgJi/fT/R6 cNo0QQnKTUoPNnMfc2z/ktkkrvHlza3UXSHqpKJ7laCTXm/XXkky7r1iDYd2MLB4 oURje7e9VhCSR4EhIgIuSYtQmZk2TCq6Re1OmRxHaGKC3zjOt5LBLf+LnC2/pUwc wHW/WQluxCU= =//WA -----END PGP SIGNATURE----- From mkousa@cc.hut.fi Thu Aug 21 22:11:02 2003 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Aug 21 21:11:02 2003 Subject: [Hipsec] RTT field in AC_INFO Message-ID: Is the RTT field really needed in the AC_INFO payload ? The current draft-nikander-hip-mm-00 does not say anything about the correct usage of this field, but I have had discussions with the HIP4BSD team on some possible uses of this field. For example, one way to use this field that was pointed out is to put a timestamp in host specific format into the RTT field of the AC packet. Then we assume that the host receiving the AC packet is not supposed to change the contents of the RTT field, so it just copies the value into the corresponding ACR packet. When ACR is received, the receiving host gets the current time and substracts the RTT field from it to get the actual RTT. However, we can assume that HIP implementations allocate some memory for the data structures needed to remember the AC packets the host has sent (like the AC ID, REA ID, and other stuff). Additionally, we can add one more field to this data structure, that is, a timestamp when the AC was sent out. The rest goes on practically the same way as before, but without using the RTT field of the AC_INFO payload. When the ACR packet is received, the host looks up its data structures if it has sent the corresponding AC. If yes, it consults the same data structure to get the timestamp when the AC was sent and substracts current time from the this saved timestamp. Therefore, we would not need the RTT field anymore. Then there are some more or less relevant issues related to the RTT field if we apply the first approach of the RTT field usage described before (that is, we assume the receiver of an ACR (from now on called as host X) trusts that the sender of the ACR (from now on called as host Y) has not altered the AC's RTT in any way): -Y's promotion of particular interface to cause more load on some route: host Y's ACR containing an altered value of the RTT might have effects on host X (e.g. for outgoing packet host X selects the peer (Y) address based on the lowest RTT value calculated). This might be an issue if Y wants to force X to send packets destined to Y using some particular route which finally ends at the interface X selected. This is not a problem if the approach I described is used, because now X can calculate the real RTT values. -information leakage of X's current time: if we know the format of the timestamp X uses in its RTT field, Y knows the (possibly even quite accurately) current time of the host X. This information might be useful if Y needs the host X's time for some attacks which need to know the peer's time. This is also not a problem if we don't have the RTT field. -paranoid people will make up more scenarios where the peer's timestamp could be useful, like a rough estimation of peer's geographical location: "peer's time is now 1 AM, let's see in which timezone the peer might be" etc. From mkousa@cc.hut.fi Thu Aug 21 22:24:04 2003 From: mkousa@cc.hut.fi (Mika Kousa) Date: Thu Aug 21 21:24:04 2003 Subject: [Hipsec] REA_INFO with no addresses listed Message-ID: In a REA_INFO payload of a REA packet, how to indicate the situation when some Interface Id has no more usable addresses (might happen if someone removes interface's all addresses intentionally or accidentally) ? Do I just leave out all the "Address Lifetime, Reserved, Address" fields and end the REA_INFO payload right after the REA ID field ? Or is the question even relevant ? From andrew@indranet.co.nz Thu Aug 28 23:44:00 2003 From: andrew@indranet.co.nz (Andrew McGregor) Date: Thu Aug 28 22:44:00 2003 Subject: [Hipsec] Re: Solving the right problems ... In-Reply-To: References: Message-ID: <85000000.1062126392@ijir> -----BEGIN PGP SIGNED MESSAGE----- - --On Thursday, August 28, 2003 07:05:19 PM +0200 Iljitsch van Beijnum wrote: > On woensdag, aug 27, 2003, at 19:51 Europe/Amsterdam, Fred Templin wrote: > >>> The hard part is coming up with a way to do the host/location mapping >>> in a way that is simple, fast, cheap, secure, flexible and reliable. > >> Wouldn't we all start deploying, e.g., HIP tomorrow if we had a >> solution for this? > > I'm not exactly current on what's happening with HIP but aren't there > supposed to be working implementations today? There are. Four of them, in fact, but none are yet production quality. If anyone wants to play or read some code, these are the available ones: Linux USAGI, IPv6 only NetBSD, dual stack Linux, Python in userspace (therefore needs no kernel IPSEC), dual stack There are drafts about the various mappings, but no implementation yet. There are also ideas around about how to transparently autodetect HIP support in the responder, with no a-priori knowledge. The (new) hipsec mailing list is at . Andrew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP07DOVGmVIGYWzvRAQFTHQP7BUYZ6x/jBX1s7yP3Oro5qEa28ABZumGY nOQwval68BsGkTjdX6qxrXbMNsnvNbLpIrY0u01/rthVSfDNTH4+FMLhUzjUl0+e 1K+H+2tygLmYCUPKf5xBOwKSgmwp9vaOMfC9EH1ZkaLmC2q7tFX3RJasBv41OG/u 1TyDMOXf5Vo= =G9KU -----END PGP SIGNATURE----- From pekka.nikander@nomadiclab.com Fri Aug 29 09:38:00 2003 From: pekka.nikander@nomadiclab.com (Pekka Nikander) Date: Fri Aug 29 08:38:00 2003 Subject: [Hipsec] MAST: A perhaps simpler alternativity to HIP? Message-ID: <3F4F4EC1.6070609@nomadiclab.com> http://brandenburg.com/specifications/draft-crocker-mast-proposal-00.txt ABSTRACT Classic Internet transport protocols use a single source IP address and a single destination IP address, as part of the identification for an individual data flow. TCP includes these in its definition of a connection and its calculation of the header checksum. Hence the transport service is tied to a particular IP address pair. This is problematic for multi-homed hosts and for mobile hosts. Both have multiple IP addresses but cannot use more than one, for any single transport association (context). Multiple Address Service for Transport (MAST) defines a mechanism that transparently supports association of multiple IP addresses with any transport association. It requires no change to the IP infrastructure, and no change to IP modules or transport modules in the end-systems. Instead, it defines a wedge layer between IP and transport that operates only in the end systems and affects only participating hosts. From rgm@htt-consult.com Fri Aug 29 09:49:01 2003 From: rgm@htt-consult.com (Robert Moskowitz) Date: Fri Aug 29 08:49:01 2003 Subject: [Hipsec] MAST: A perhaps simpler alternativity to HIP? In-Reply-To: <3F4F4EC1.6070609@nomadiclab.com> Message-ID: <5.1.0.14.2.20030829060823.0300c9f0@localhost> If this is what I think it is, it is equivelant to a HI that is not cryptographic. With all the warnings the HIP architecture has about such an approach. At 04:01 PM 8/29/2003 +0300, Pekka Nikander wrote: >http://brandenburg.com/specifications/draft-crocker-mast-proposal-00.txt > > ABSTRACT > > Classic Internet transport protocols use a single source IP > address and a single destination IP address, as part of the > identification for an individual data flow. TCP includes > these in its definition of a connection and its calculation > of the header checksum. Hence the transport service is tied > to a particular IP address pair. This is problematic for > multi-homed hosts and for mobile hosts. Both have multiple > IP addresses but cannot use more than one, for any single > transport association (context). Multiple Address Service > for Transport (MAST) defines a mechanism that transparently > supports association of multiple IP addresses with any > transport association. It requires no change to the IP > infrastructure, and no change to IP modules or transport > modules in the end-systems. Instead, it defines a wedge > layer between IP and transport that operates only in the end > systems and affects only participating hosts. > > > >_______________________________________________ >Hipsec mailing list >Hipsec@honor.trusecure.com >http://honor.trusecure.com/mailman/listinfo/hipsec From thomas.r.henderson@boeing.com Fri Aug 29 15:41:00 2003 From: thomas.r.henderson@boeing.com (Henderson, Thomas R) Date: Fri Aug 29 14:41:00 2003 Subject: [Hipsec] MAST: A perhaps simpler alternativity to HIP? Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C026B5988@xch-nw-27.nw.nos.boeing.com> This seems most like a generalization of the SCTP approach. Some differences with respect to HIP: - uses nonces instead of permanent HIs - does not require setup to precede transport session initiation - it makes a different choice with respect to NAT handling-- HIT effectively substitutes IPsec protection for transport checksums. MAST tries to keep use of transport checksum. The difficulty in this approach is that MAST must then know at the end system how a NAT may transform its IP addresses and port numbers. It proposes a PROBE message for this. =20 If the addresses learned by the PROBE reliably map to the addresses that the NAT will use for a subsequent TCP segment, then it=20 probably can work, although I am not sure that all NATs will=20 transform the PROBE and the subsequent TCP segment to the same port number. Tom From Dave Crocker Fri Aug 29 21:10:01 2003 From: Dave Crocker (Dave Crocker) Date: Fri Aug 29 20:10:01 2003 Subject: [Hipsec] Multiple Address Service for Transport (MAST) Message-ID: <135119729251.20030829173325@brandenburg.com> Howdy, I've just posted a new mobility/multi-homing proposal as an internet-draft. The multi6 mailing list is probably the most appropriate venue for discussing this proposal, so it is the only address showing in the TO field. However, HIP is more than slightly relevant, since my proposal is related. That said, the differences are significant. The I-D name is: draft-crocker-mast-proposal-00.txt It is also available at: Herewith the abstract for the proposal: Classic Internet transport protocols use a single source IP address and a single destination IP address, as part of the identification for an individual data flow. TCP includes these in its definition of a connection and its calculation of the header checksum. Hence the transport service is tied to a particular IP address pair. This is problematic for multi-homed hosts and for mobile hosts. Both have multiple IP addresses but cannot use more than one, for any single transport association (context). Multiple Address Service for Transport (MAST) defines a mechanism that transparently supports association of multiple IP addresses with any transport association. It requires no change to the IP infrastructure, and no change to IP modules or transport modules in the end-systems. Instead, it defines a wedge layer between IP and transport that operates only in the end systems and affects only participating hosts. As the document notes a couple of times, this is an extended proposal, rather than a complete specification. It's being put forward in the current form to solicit comments about the approach and the design, and to find out whether folks are interested in pursuing it further. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA , From dcrocker@brandenburg.com Sat Aug 30 01:12:01 2003 From: dcrocker@brandenburg.com (Dave Crocker) Date: Sat Aug 30 00:12:01 2003 Subject: [Hipsec] MAST: A perhaps simpler alternativity to HIP? Message-ID: <39134244893.20030829213521@brandenburg.com> First, I need to apologize. I missed the mailing list transition, so my original attempt to copy the announcement to the list failed, yesterday. Second, thanks to Pekka for posting it. As to technical matters: > If this is what I think it is, it is equivelant to a HI that is not > cryptographic. With all the warnings the HIP architecture has about such > an approach. My feeling is that it is essential to have adequate security, but it is equally essential to be clear what that means, in this case. My view is that adequate security means protection against spoofing, on a par with the protection that is present for a regular TCP connection. Hence, there needs to be very strong protection against falsely inserting a new address into the working set for an association. But there does not need to be any other security, since none is present in a regular TCP connection. SCTP's mechanism is probably fine, but my reaction to DCCP's equivalent mechanism was that it is stronger. I have no religion on this point and frankly can't do more than an amateur's job of designing it myself. That's why I was delighted to see the SCTP and DCCP mechanism. I had originally felt compelled to use BEEP and SASL for this, which is gross overkill. That said, I've no doubt the details of the security design need to be better. > - it makes a different choice with respect to NAT handling-- > HIT effectively substitutes IPsec protection for transport > checksums. MAST tries to keep use of transport checksum. > The difficulty in this approach is that MAST must then > know at the end system how a NAT may transform its IP > addresses and port numbers. It proposes a PROBE message for this. =20 > If the addresses learned by the PROBE reliably map to the addresses > that the NAT will use for a subsequent TCP segment, then it=20 > probably can work, although I am not sure that all NATs will=20 > transform the PROBE and the subsequent TCP segment to the same > port number. mumble... good point... grrr... yes, I had been thinking that a NAT would behave the same for a stray protocol, like MAST, as it does for TCP. As you point out, it might not, though I'm wondering what the choices are. Either a NAT works for arbitrary programs or it only works for a (tiny) few. The odds that a NAT will use highly varied schemes for random protocols seems unlikely to me. Tailored behavior for special, known protocols, like FTP, is one thing. Varied behavior for random protocols is another. Does anyone have direct knowledge about this? d/ /d -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA ,