Subject: [secdir] SECDIR review of draft-ietf-softwire-mesh-framework-05

From: Julien Laganier <[email-masked]>
Date: Tue, 16 Dec 2008 16:35:44 +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.

This draft describes a framework allowing a single version (4 or 6) IP 
network to provide transite service for the other version of IP. The 
framework describes a method by which 1) routing information, and 2) 
packets for the other version of the protocol are passed from one edge 
of the single protocol network to the other edge.

As a framework document most of the protocol level security issues are 
probably with the accompanying protocol specifications themselves. I 
however have some comments on part of the "Security Considerations" 
section.

In section 14.1 "Problem Analysis":
-----------------------------------

"
   Since the encapsulation headers determine the routing of packets
   traveling through softwires, they must appear "in the clear", i.e.,
   they do not have any confidentiality requirement.
"

I'm not sure about the "i.e." and what follows... 

On the contrary there seems to be a requirement that confidendiality 
protection is not applied to the headers. Suggest removing "i.e." and 
what follows.

"
   In the Softwires mesh framework, for each tunnel receiving endpoint,
   there are one or more "valid" transmitting endpoints, where the valid
   transmitting endpoints are those which are authorized to tunnel
   packets to the receiving endpoint.  If the encapsulation header has
   no guarantee of authentication or integrity, then it is possible to
   have spoofing attacks, in which unauthorized nodes send encapsulated
   packets to the receiving endpoint, giving the receiving endpoint the
   invalid impression the encapsulated packets have really traveled
   through the softwire.  Replay attacks are also possible.

   The effect of such attacks is somewhat limited though.  The receiving
   endpoint of a softwire decapsulates the payload and does further
   routing based on the IP destination address of the payload.  Since
   the payload packets are traveling through the Internet, they have
   addresses from the globally unique address space (rather than, e.g.,
   from a private address space of some sort).  Therefore these attacks
   cannot cause payload packets to be delivered to an address other than
   the one intended.
"

I'm finding the use of the term "intended" in the last sentence 
misleading. If an attacker is indeed spoofing an ingress softwire 
endpoint and trying to inject arbitrary IP packets into the E-IP 
network at the exit point of the softwire, what's the significance 
ofthe "intended" destination address? If it's the one intended by the 
attacker then it's kind of tautologic, and there's indeed a problem, 
which seems acknowledged in the next paragraph:

"
   However, attacks of this sort can result in policy violations.  The
   authorized transmitting endpoint(s) of a softwire may be following a
   policy according to which only certain payload packets get sent
   through the softwire.  If unauthorized nodes are able to encapsulate
   the payload packets so that they arrive at the receiving endpoint
   looking as if they arrived from authorized nodes, then the properly
   authorized policies have been side-stepped.
"

I suggest that the paragraph that contains the text on the "intended" 
destination is simply completely removed since it does not seem to add 
to the rest of the text.

"
   Attacks of the sort we are considering can also be used in Denial of
   Service attacks on the receiving tunnel endpoints.  However, such
   attacks cannot be prevented by use of cryptographic
   authentication/integrity techniques, as the need to do cryptography
   on spoofed packets only makes the Denial of Service problem worse.
"

It would be good to understand the sort of flooding attacks you are 
considering here (e.g. flooding attacks on the link supporting the 
softwire) so that the statement that integrity protection is of no used 
can be assessed.

In section 14.3 "Cryptographic Techniques"
------------------------------------------

"  
   [...]
   If it is deemed necessary to use tunnels that are protected by IPsec,
   the tunnel type SHOULD be negotiated by the tunnel endpoints using
   the procedures specified in [ENCAPS-IPSEC].  That document allows the
   use of IPsec tunnel mode, but also allows one to treat the tunnel
   head and the tunnel tail as the endpoints of a Security Association,
   and to use IPsec transport mode.
"

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 above paragraph as 
well as in the IPsec encapsulation document [ENCAPS-IPSEC]. 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.
"

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

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