![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
At 9:02 -0500 3/31/98, Perry E. Metzger wrote: >"Howard C. Berkowitz" writes: >> I may have missed a writeup that already exists, > >Such as the documents we are discussing, yes.... You mean obscure things like draft-ietf-ipsec-arch-sec-04.txt? I recognize there are other working documents, but this is Last Call for a specific one, which doesn't appear to reference certain issues. Issues about which prominent members of the community are extremely vocal -- well, more vocal than usual :-) > >> but the two quotes below add to my feeling there needs to be a clear >> architectural discussion of: > >The issues you raise are discussed in the documents. Please read them. > >Perry Yes: such as >. This document does not address all aspects of IPsec > architecture. Subsequent documents will address additional > architectural details of a more advanced nature, e.g., use of IPsec > in NAT environments and more complete support for IP multicast NAT and routing are more my areas than the satellite issues. Nevertheles, in an architecture document, I would like more meat that a "To be addressed." I'd like an initial statement of problems in the interctions between NAT/firewalls and IPsec, with emphasis on vulnerability. Sandy Murphy;s BGP Security Analysis is the sort of document I have in mind. The architecture document doesn't need to contain this, but there should be a reasonable pointer, which I don't see. The emphasis is on the protocols and protocol entities rather than their deployment. Howar
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.