[dtn] Fwd: Uncaught bounce notification

[Marc Blanchet <[e-mail]>]

> Début du message réexpédié :
> 
> Objet: Uncaught bounce notification
> De: [e-mail]
> À: [e-mail]
> Date: 23 février 2015 11:29:23 UTC−5
> 
> The attached message was received as a bounce, but either the bounce
> format was not recognized, or no member addresses could be extracted
> from it.  This mailing list has been configured to send all
> unrecognized bounce messages to the list administrator(s).
> 
> For more information see:
> https://www.ietf.org/mailman/admin/dtn/bounce <https://www.ietf.org/mailman/admin/dtn/bounce>
> 
> 
> De: "Sheehe, Charles J. (GRC-LCA0)" <[e-mail] <mailto:[e-mail]>>
> À: dtn <[e-mail] <mailto:[e-mail]>>
> Objet: DTN Security
> Date: 23 février 2015 11:29:14 UTC−5
> 
> 
> Hi 
> Over the last couple of days I have reviewed IEEE 1609-2 security for V2V communications.
> They have chosen to go a different path than us.
>  
> Reviewed the Delay-Tolerant Networking Security Overview draft-irtf-dtnrg-sec-overview-03
> I have re-read RFC 4838.
> From these the closest thing to a threat and vulnerability analysis I have found for DTN. The header and payloads should be separated and that the header must be checked and validated prior to any processing of the payloads.
> The payloads as standalone items should have sufficient information included in order to authenticate and secure them. 
>  
> Chuck
>  
>  
> “RFC 4834
> #3.14
> The possibility of severe resource scarcity in some delay-tolerant networks dictates that some form of authentication and access control to the network itself is required in many circumstances.  It is not acceptable for an unauthorized user to flood the network with traffic easily, possibly denying service to authorized users.  In many cases it is also not acceptable for unauthorized traffic to be forwarded over certain network links at all.  This is especially true for exotic, mission-critical links.  In light of these considerations, several goals are established for the security component of the DTN architecture:
> - Promptly prevent unauthorized applications from having their data carried through or stored in the DTN.
> - Prevent unauthorized applications from asserting control over the DTN infrastructure.
> - Prevent otherwise authorized applications from sending bundles at a rate or class of service for which they lack permission.
> - Promptly discard bundles that are damaged or improperly modified in transit.
> - Promptly detect and de-authorize compromised entities.
>  
> Many existing authentication and access control protocols designed for operation in low-delay, connected environments may not perform well in DTNs.  In particular, updating access control lists and revoking ("blacklisting") credentials may be especially difficult. Also, approaches that require frequent access to centralized servers to complete an authentication or authorization transaction are not attractive.  The consequences of these difficulties include delays in the onset of communication, delays in detecting and recovering from system compromise, and delays in completing transactions due to    inappropriate access control or authentication settings. To help satisfy these security requirements in light of the challenges, the DTN architecture adopts a standard but optionally deployed security architecture [DTNSEC] that utilizes hop-by-hop and end-to-end authentication and integrity mechanisms.  The purpose of using both approaches is to be able to handle access control for data   forwarding and storage separately from application-layer data integrity.  While the end-to-end mechanism provides authentication for a principal such as a user (of which there may be many), the hop-by-hop mechanism is intended to authenticate DTN nodes as legitimate transceivers of bundles to each-other.  Note that it is conceivable to construct a DTN in which only a subset of the nodes participate in the security mechanisms, resulting in a secure DTN overlay existing atop an insecure DTN overlay.  This idea is relatively new and is still being explored.
> In accordance with the goals listed above, DTN nodes discard traffic as early as possible if authentication or access control checks fail. This approach meets the goals of removing unwanted traffic from being forwarded over specific high-value links, but also has the associated benefit of making denial-of-service attacks considerably harder to mount more generally, as compared with conventional Internet routers.
> However, the obvious cost for this capability is potentially larger computation and credential storage overhead required at DTN nodes.
> For more detailed information on DTN security provisions, refer to [DTNSEC] and [DTNSOV].
>  
> From:  DTNSOV Open Issues
> 5.
> This section discusses some of the issues which are still very open, either due to a lack of consensus in the DTNRG, or due to there being areas (like DTN key management) where much basic research remains to be done.
> Where an issue has been discussed previously (e.g. source confidentiality), we will not include it here again.
> 5.4. Routing protocol security
> Clearly whenever DTN routing protocols are defined they will introduce new security requirements, or at least change the emphasis to be properly placed on meeting the various requirements posited above. For example, one could expect that a robust and scalable origin-authentication scheme would become more important.
> At the time of writing there are no well-documented DTN routing protocols, so DTN routing protocol security must clearly be in our list of open issues. However, if a putative DTN routing protocol were to use either the Bundle protocol or LTP, it could clearly make use of their existing security features.”
>  
> Charles J. Sheehe III
> Electronics Engineer
> System Architectures and Networks Branch
> 21000 Brookpark Rd
> Cleveland, OH 44135
> [e-mail] <mailto:[e-mail]>
> Office: 216-433-5179