Subject: [secdir] SECDIR review of draft-ietf-softwire-encaps-ipsec-01

From: Julien Laganier <[email-masked]>
Date: Tue, 16 Dec 2008 17:00:31 +0100

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG. These comments were written primarily for the benefit of the  
security area directors. Document editors and WG chairs should treat  
these comments just like any other last call comments.

I'm no BGP expert thus I'm simply copy/pasting the draft's Abstract 
below to give people some background:

   The BGP Encapsulation Subsequence Address Family Identifiers (SAFI)
   provides a method for the dynamic exchange of encapsulation
   information, and the indication of encapsulation protocol types to be
   used for different next hops.  Currently support for GRE and L2TPv3
   tunnel types are defined.  This document defines support for IPsec
   tunnel types.

The document is short and thus I have few comments:

In section 2. "IPsec Tunnel Encapsulation Types"
------------------------------------------------

"
   Per [ENCAPS-SAFI], tunnel type is indicated in the Tunnel
   Encapsulation attribute. This document defines the following tunnel
   type values:

     - AH in Tunnel-mode: Tunnel Type = 3 [RFC4302]

     - ESP in Tunnel-mode: Tunnel Type = 4 [RFC4303]

     - IP-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 5
       [RFC4023]
"

I made the same comment for the softwire framework draft but I'm 
repeating it here for completeness: The use of IPsec transport mode to 
protect tunnels is diminished significantly compared to the protection 
afforded by IPsec tunnel mode and thus it would be good to point that 
out in the Security Considerations section of this document. For 
example RFC 4301 includes the following paragraph:

"
                                                    [...] The access
   control functions that are an important part of IPsec are
   significantly limited in this context, as they cannot be applied to
   the end-to-end headers of the packets that traverse a transport mode
   SA used in this fashion.  Thus, this way of using transport mode
   should be evaluated carefully before being employed in a specific
   context.
"

In section 3 "Use of IPsec"
---------------------------

"
   If a R1 is a BGP speaker that receives an Encapsulation SAFI update
   from another BGP speaker, R2, then if R1 has any data packets for
   which R2 is the BGP next hop, R1 MUST initiate an IPsec SA of the
   specified "tunnel type", and all such data packets MUST be sent
   through that SA.

   Let R1 and R2 be two BGP speakers that may send data packets through
   R3, such that the data packets from R1 and from R2 may be received by
   R3 over the same interface.  Then if R3 has sent an update containing
   an Encapsulation SAFI, and if this update specifies an IPsec tunnel
   type, and if this update is received by R2, and an Encapsulation-SAFI
   with an IPsec tunnel type, SHOULD also be received by R1. [..]
"

Maybe this is just me but I have read the last sentence above 5 or 6 
times and I have trouble to parse it. It seems to be some comas should 
disappear. Would this rewording be appropriate: 

"If R3 has sent an update containing an Encapsulation SAFI that 
specifies an IPsec tunnel type to R2, then an update containing an 
Encapsulation SAFI that specifies an IPsec tunnel SHOULD also be 
received by R1" ?

Nits:
-----

In couple of places you're using a reference to a document as a 
grammatical object while I understand a reference has a parenthetical 
nature and thus can't play that role.

E.g. "This document does not specify the use of the sub-TLV types 
defined in [ENCAPS-SAFI] with these tunnel types."

Should be reworded into something like "This document does not specify 
the use of the sub-TLV types defined in the BGP Information SAFI and 
BGP Tunnel Encapsulation Attribute specification [ENCAPS-SAFI] with 
these tunnel types."

This is all for this document. Hope this is useful.

--julien
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir