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

From: Eric Rosen <[email-masked]>
Date: Thu, 29 Jan 2009 11:25:05 -0500

Sorry, somehow I didn't notice this review when it was posted.

Julien> In section 14.1 "Problem Analysis":

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

Julien> Suggest removing "i.e." and what follows.

Agreed.

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

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

Julien> I'm finding the use of the term "intended" in the last sentence 
Julien> misleading. 

I  will  replace  "the  one  intended"  by "the  one  appearing  in  the  IP
destination address field of the payload packet".

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

The point  is that the tunnel  egress will still forward  the payload packet
based on the contents of the payload packet's IP destination address field.

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

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

The assumption  is that the crypto  mechanisms are likely to  be more costly
than the decapsulation/forwarding mechanisms.   So if one tries to eliminate
a  flooding  attack  on  the decapsulation/forwarding  mechanisms  by  using
cryptographic integrity,  one ends  up just trading  one kind of  attack for
another. 

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

Julien> The use of IPsec transport mode to protect tunnels is diminished 
Julien> significantly compared to the protection afforded by IPsec tunnel mode 
Julien> and thus it would be good to point that out in the above paragraph as 
Julien> well as in the IPsec encapsulation document [ENCAPS-IPSEC]. For example 
Julien> RFC 4301 includes the following paragraph:

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

I believe this is adequately  addressed in section 14.1, "Problem Analysis".
Or do you see something that would make tunnel mode useful in this context?

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