Subject: RFC 4365 errata

From: Alfred Hönes <[email-masked]>
Date: Mon, 20 Mar 2006 12:34:48 +0100 (MEZ)

Hello,
I'd like to report a few textual issues I found in your recently
published RFC 4365 (BGP/MPLS IP VPN Applicability).  I propose
to post an Errata Note for RFC 4365 to resolve these issues.

To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').

(1)  Section 6.2 (SP Security Measures)

The first paragraph of Section 6.2, on page 10, contains the sentence:

            [...].  VPN traffic is always encapsulated while traveling
   on the backbone, so preventing illegitimate traffic is a matter of
   ensuring that the PE routers to the encapsulation/decapsulation
   correctly and that encapsulations have not been "spoofed", i.e., that
   the encapsulated packets were actually encapsulated by PE routers.

It should say:

            [...].  VPN traffic is always encapsulated while traveling
   on the backbone, so preventing illegitimate traffic is a matter of
|  ensuring that the PE routers do the encapsulation/decapsulation
   correctly and that encapsulations have not been "spoofed", i.e., that
   the encapsulated packets were actually encapsulated by PE routers.
                               ^^^

(2)  Section 6.3 (Security Framework Template)

The 4th paragraph on page 15 says:

       If these are desired, they must be provided by mechanisms that
       are outside the scope of the VPN mechanisms.  For instance, the
       users can use secure protocols on an end-to-end basis, e.g.,
       IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc.

It should say:

       If these are desired, they must be provided by mechanisms that
       are outside the scope of the VPN mechanisms.  For instance, the
       users can use secure protocols on an end-to-end basis, e.g.,
|      IPsec, Secure Shell (SSH), Transport Layer Security (TLS), etc.
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Rationale:
  SSL had subtle, but significant security flaws.
  This was one of the reasons for the IETF to develop a Standards
  Track successor (TLS) to that proprietary protocol.
  IMHO, it would be very much preferrable for a companion document
  (like RFC 4365) to an IETF Standards Track protocol (RFC 4364)
  to refer to the more secure IETF Standards Track solution.

(3)  Section 6.3 (Security Framework Template), again

The last paragraph at the bottom of page 15 says:

           In the common case where the tunnels are MPLS Label Switching
           Routers (LSRs) established by LDP, then control message
           integrity and peer authentication may be achieved by use of
           the TCP MD5 option.

It should say:

|          In the common case where the tunnels are MPLS Label Switched
|          Paths (LSPs) established by LDP, then control message
           integrity and peer authentication may be achieved by use of
           the TCP MD5 option.

Rationale:
  It would indeed save much money to ISPs if they could create Label
  Switching *Routers* (LSRs) via LDP.  But it doesn't work.  :-)
  [ Surely, the employer of the author wouldn't be happy so much! ]

(4)  Section 12 (Migration Impact)

The first sentence of Section 12, on page 22, says:

   Generally, this means replacement of an existing legacy backbone with
   VPN backbone.  [...]

It should say:

   Generally, this means replacement of an existing legacy backbone with
|  a VPN backbone.  [...]
   ^^

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+