ikev2-13 section 1.1.2 end-to-end diagram says "tunnel" add reference to RFC 1958, 2775, etc

["William Dixon" <ietf-wd@v6security.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While end-to-end tunnel mode is certainly still allowed, this diagram
is inconsistent with the section heading. It should say "IPsec tunnel
mode or IPsec transport mode", not just "IPsec tunnel". Yes, I
clearly see the text explains. But you probably wouldn't believe the
confusion in the customer base who don't get "transport mode", and if
they don't see it in the picture, they think and say and then can't
stop saying "tunnel" even if they mean transport.

Further, I'd like to see consistency with terminology and a reference
that this protocol in this scenario enabling the end-to-end security
vision for the Internet discussed in IAB informational RFCs 1958 and
2775 (ftp://ftp.rfc-editor.org/in-notes/rfc2775.txt).


Current text:

1.1.2 Endpoint to Endpoint Transport


       +-+-+-+-+-+                                         
+-+-+-+-+-+
       !         !                 IPsec                    !        
!
       !Protected!                 Tunnel                  
!Protected!
       !Endpoint !<---------------------------------------->!Endpoint
!
       !         !                                          !        
!
       +-+-+-+-+-+                                         
+-+-+-+-+-+


                       Figure 2:  Endpoint to Endpoint


   In this scenario, both endpoints of the IP connection implement
   IPsec. These endpoints may implement application layer access
   controls based on the authenticated identities of the
participants.
   Transport mode will commonly be used with no inner IP header. If
   there is an inner IP header, the inner addresses will be the same
as
   the outer addresses. A single pair of addresses will be negotiated
   for packets to be protected by this SA.


Suggested replacement text:

1.1.2 Endpoint to Endpoint Transport


       +-+-+-+-+-+                                         
+-+-+-+-+-+
       !         !                 IPsec transport          !        
!
       !Protected!                 or tunnel mode SA       
!Protected!
       !Endpoint !<---------------------------------------->!Endpoint
!
       !         !                                          !        
!
       +-+-+-+-+-+                                         
+-+-+-+-+-+


                       Figure 2:  Endpoint to Endpoint


   In this scenario, both endpoints of the IP connection implement
   IPsec, as required of hosts in [RFC 2401]. Transport mode will 
   commonly be used with no inner IP header. If there is an inner IP 
   header, the inner addresses will be the same as the outer
addresses. 
   A single pair of addresses will be negotiated for packets to be 
   protected by this SA. These endpoints may implement application
layer
   access controls based on the IPsec authenticated identities of the
   participants. This scenario enables the end-to-end security that
has 
   been a guiding principle for the Internet since [RFC 1958], [RFC2
775],
   and a method of limiting the inherent problems with complexity in 
   networks noted by [RFC 3439]. While this scenario may not be fully
   applicable to the IPv4 Internet, it has been deployed with
successfully
   in specific scenarios within intranets using IKEv1. It should be
more
   broadly enabled during the transition to IPv6 and with the
adoption
   of IKEv2.
 

Adding references:

   [RFC 1958]    Carpenter, B., "Architectural Principles of the
                 Internet", RFC 1958, June 1996.

   [RFC 2775]    Carpenter, B., "Internet Transparency", RFC 2775,
February
                 2000.

   [RFC 3439]    Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines
                 and Philosophy", RFC 3429, December 2002.


Thanks,
Wm

V6 Security, Inc.
http://www.v6security.com


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQGzn/3eaysMUl8VcEQKobgCg7CU4DmNccm/Veq/UGWEt83Xsct0AoLZL
CenvU1BvhbN10Mrd/7uP+CRP
=HlIu
-----END PGP SIGNATURE-----