RE: Security draft issue (4) - IPsec
"Caitlin Bestler" <[email protected]>
| Newsgroups | gmane.ietf.rddp |
|---|---|
| Message-ID | <[email protected]> |
[email protected] said: > Caitlin, > >> I do not see any RDDP specific vulnerabilities that are relevant >> to the use of IPsec. >> >> A non-RDDP application enables reception of peer messages into >> application buffers. Given the nature of non-RDDP LLPs, use >> of intermediate system buffering is likely. >> >> Once received, the Application judges the applicability of >> transport layer security to its needs. It may determine that >> the transport has provided sufficient authentication of the >> remote peer to allow acting upon the received messages without >> further validation, or it may decide to apply its own validation. >> >> So what changes with RDDP? >> >> Nothing, except that the intermediate system buffering is >> far less likely. That *improves* security, not worsens it. >> >> Whether or not IPsec is in use, the Application already >> has full control of which of its buffers are exposed, >> to what extent, and for how long. Procedures to precisely >> control that exposure are already documented in the security >> draft and are not dependent on the use of IPsec or other >> transport layer security. > > I think this misses the point by focusing on data instead of > control. The thing that has changed is that RDDP exposes > a new functional interface for use over the network, providing > more opportunities for abuse by a rogue peer who misuses the > interface or an attacker who modifies the headers in transit > - the security exposure here involves the headers and the > additional functionality they enable. In contrast to other > new functionality, the application has no possibility to > perform "its own validation" on use of the RDDP placement > interface because the application never sees the RDDP headers. > What has not changed is that no matter what is in the network packet, the exposure of application buffers to those packets is under control of the application -- not of the network packet. How precisely the application control the exposure of its buffer space, relative to its security requirements, is the real issue. The vulnerability of network packets is not an RDDP specific issue. If the application has tailored its exposure, the attacker can modify the headers endlessly. They will still only be able to deposit the payload in the buffers the Data Sink ULP intended them to be deposited into. Again, the only change from non-RDDP applications is that the use of intermediate system buffering has been eliminated. This represents *improved* security, not heightened risk. -- Caitlin Bestler http://asomi.com/