Re: Comments on draft-nordmark-multi6-threats-01

[Erik Nordmark <Erik.Nordmark@sun.com>]

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.

Should we make it explicit that the identifiers are not (necessarily) tied
to an interface?

>  > 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.


>  >     FQDN        - Fully Qualified Domain Name
> 
> I would add a reference to RFC 1594, which seems to be the only place
> that FQDN is defined

Or FYI18/RFC1983.

   Erik