Thanks for the comments. A few followup questions below.
This document doesn't assume that the application protocols are
protected by strong security today or in the future. However, it is
still useful to assume that the application protocols which care
about integrity and/or confidentiality apply the relevant end-to-end
security measures, such as IPsec or TLS.
That's a narrow view of e2e security; I would add "and/or applications
level security."
I thought "such as" implied that they were examples and not a complete list.
I can rephrase this to be more inclusive though.
interface - a node's attachment to a link.
Is this intended to include virtual or pseudo interfaces
such as tunnel end points?
Include. I'll copy the rfc 2460 definition of "link" into the draft
to make this more clear since it explicitly talks about tunnels.
address - an IP layer name that contains both topological
significance and acts as a unique identifier for an
interface.
There may be multiple addresses per interface.
Added.
locator - an IP layer topological name for an interface or a
set of interfaces.
There may be multiple locators per interface.
Added.
identifier - an IP layer identifier for an IP layer endpoint
(stack name in [NSRG]). The transport endpoint is a
function of the transport protocol and would
typically include the IP identifier plus a port
number.
Do we believe there may be multiple identifiers per interface or per host?
I think there is utility to have multiple identifiers per stack/host.
For example due to privacy concerns, when using different (and changing over
time) identifiers for certain outbound connections while still having
one (or more) identifiers for inbound communication.
> 3.1. Application Assumptions
...
The second class of applications use existing IP source addresses
from outside of their immediate local site as a means of
authentication without any form of verification. Today, with source
IP address spoofing and TCP sequence number guessing as rampant
attacks, such applications are effectively opening themselves for
public connectivity and are reliant on other systems, such as
firewalls, for overall security. We do not consider this class of
systems in this document.
...because they are in any case fully open to all forms of network
layer spoofing.
Added.
The third class of applications receive existing IP source addresses,
but attempt some verification using the DNS, effectively using the
FQDN for access control. (This is typically done by performing a
reverse lookup from the IP address followed by a forward lookup and
verifying that the IP address matches one of the addresses returned
from the forward lookup.) These applications are already subject to
a number of attacks using techniques like source address spoofing and
TCP sequence number guessing since an attacker, knowing this is the
case, can simply create a DoS attack using a forged source address
that has authentic DNS records. In general this class of
applications is strongly discouraged, but it is probably important
that a multihoming solution doesn't introduce any new and easier ways
to perform such attacks.
But do we desire to make reverse lookup checks for multihomed sites
succeed, to avoid multihoming failures for hosts using the broken
technique?
For "application compatibility" I think we want to ensure that the
reverse+forward lookups applications do today don't work any less.
But that isn't driven by the threats - it's driven by trying for
as much compatibility as possible.
Should the threats document say something about this?
Finally, the fifth class of applications use cryptographic security
techniques but without strong identity (such as opportunistic IPsec).
Thus data integrity with or without confidentiality is provided when
communicating with an unknown/unauthenticated principal. Just like
the first category above such applications can't perform access
control since they do not know the identity of the peer.
This is true *at network level* but they may well have applications
level strong identity and that may be necessary and sufficient.
Correct. I'll add that. Suggested new text for the last sentence:
Just like the first category above such
applications can't perform access control based on network layer information
since they do not know the identity of the peer. However, they might perform
access control using higher-level notions of identity.