![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
At 02:08 PM 3/31/98 -0500, Howard C. Berkowitz wrote: >Let me try to rephrase. Yes, I have read the spec and understand these >modes are present. I am raising concerns about the applicability of these >modes, since some significant user communities have insisted on >host-to-host, a technique that can complicate administration and make it >extremely difficult to use some infrastructure techniques such as NAT. The >issue of a trusted NAT has been dismissed by some. There are some cases where a trusted NAT can be used, and I have covered it in some of my presentations (and soon writings). However, there are cases where there can be no trust delegated to an intermediate system, even in corporate america (ie this is not just a DOD issue). End to End needs to be supported. ESP tunnel mode seems to be able to traverse a NAT, but IKE may well have problems setting up a SPI for such a connection. I'd simply like to see >more security analysis alternatives in the document or referenced by it. >Otherwise, I have the sense of several working groups each saying "this is >our protocol/mechanism and it's irrelevant how other mechanisms interact >with it." > > > >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.