<#part sign=pgpmime>

>>>>> "Paul" == Paul Hoffman <[email protected]> writes:
    >> Interesting. I always considered the requirement of a trust
    >> relationship of some kind an inherent part of "VPN" (of any kind,
    >> SSL, IPsec or otherwise), and assumed most people did.

    Paul> Mark, meet Michael Richardson and friends. :-)

Why?  A VPN implies trust, and you leverage it.

An RFC4322 OE system provides privacy, and we go out of our way to
distinguish it from trust.  The letters VPN occur three times in
RFC4322, and each time to help say, "unlike.."

RFC4322 tells you how much to trust the packets (not very much), because
you know from which anchor you got the "trust".  If your trust anchor is
stronger, then you can do more things with them.

What I've said repeatedly is that a system that implements RFC4322 OE
likely already has all the mechanisms to implement P2PVPN.

Here is a section.  We are clearly building a configured tunnel.
The question is how does the configuration occur.  

1.2.  Encryption Regimes

   To aid in understanding the relationship between security processing
   and IPsec, we divide policies controlling network traffic into four
   categories.  The traffic is categorized by destination address using
   longest prefix match.  Therefore, each category is enumerated by a
   set of network prefixes.  The categories are mutually exclusive; a
   particular prefix should only occur in one category.

   * Deny: network prefixes to which traffic is always forbidden.
   * Permit: network prefixes to which traffic in the clear is
     permitted.
   * Opportunistic tunnel: network prefixes to which traffic is
     encrypted if possible, when it otherwise might be sent in the
     clear.
   * Configured tunnel: network prefixes to which traffic must be
     encrypted, and traffic in the clear is never permitted.  A
     traditionally defined Virtual Private Network (VPN) is a form of
     configured tunnel.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email protected] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                       then sign the petition. 
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to