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

Erik,

Thanks. My personal responses inserted...

Erik Nordmark wrote:
> 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.

I agree.

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

I think so.

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

It probably belongs in draft-lear-multi6-things-to-think-about
rather than here.

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

Fine

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

Yes, that's better.

     Brian