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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Jun 2004 17:07:43 +0200

Substantive comments:

> 1.1.  Assumptions
...
> 
>    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."

> 2.  TERMINOLOGY
...
> 
>       interface   - a node's attachment to a link.

Is this intended to include virtual or pseudo interfaces
such as tunnel end points?

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

> 
>       locator     - an IP layer topological name for an interface or a
>                     set of interfaces.

There may be multiple locators per interface.

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

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

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

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

Nits:

 > 2.  TERMINOLOGY
...
 >     FQDN        - Fully Qualified Domain Name

I would add a reference to RFC 1594, which seems to be the only place
that FQDN is defined

> 3.1.  Application Assumptions
> 
>    In the Internet today, the initiating part of applications either
>    starts with a FQDN, which it looks up in the DNS, or already has an
>    IP address from somewhere.  For the FQDN to IP address lookup the
>    application effectively places trust in the DNS.  Once it has the IP
>    address, the application places trust in the routing system
>    delivering packets to that address.  Applications that use security
>    mechanisms, such as IPsec or TLS, with mutual authentication have the
>    ability to "bind" the FQDN to the cryptographic keying material thus
--------------------------------------------------------------------^^
missing punctuation
>    compromising the DNS and/or the routing system can at worst cause the
>    packets to be dropped or delivered to an entity which does not posses
>    the keying material.

...
> 5.  GRANULARITY OF REDIRECTION
> 
>    Different multihoming solutions might approach the problem at
>    different layers in the protocol stack.  For instance, there has been
------------------------------------------------------------------^^^
grammar
>    proposals on a shim layer inside IP as well as transport layer
---------------^^
grammar
>    approaches.  

     Brian

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 7 Jun 2004 16:14:52 -0700 (PDT)

Thanks for the comments. A few followup questions below.

> That's a narrow view of e2e security; I would add "and/or applications

I thought "such as" implied that they were examples and not a complete list.
I can rephrase this to be more inclusive though.

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

> There may be multiple addresses per interface.

Added.

> There may be multiple locators per interface.

Added.

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

> ...because they are in any case fully open to all forms of network

Added.

> succeed, to avoid multihoming failures for hosts using the broken

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?

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

> I would add a reference to RFC 1594, which seems to be the only place

Or FYI18/RFC1983.

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jun 2004 15:25:07 +0200

Erik,

Thanks. My personal responses inserted...

> one (or more) identifiers for inbound communication.

I agree.

> Should we make it explicit that the identifiers are not (necessarily) tied

I think so.

> Should the threats document say something about this?

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

>   access control using higher-level notions of identity.

Fine

>>I would add a reference to RFC 1594, which seems to be the only place

Yes, that's better.

     Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 8 Jun 2004 22:22:04 +0200

> one (or more) identifiers for inbound communication.

One very pragmatic reason: if you allow only one management becomes a 
nightmare as any identifier change is a flag day event. (This is why 
RFC 2385 never got off the ground until people were convinced the net 
as a whole would melt down without it.)

> Should we make it explicit that the identifiers are not (necessarily) 

Yes, and we should make it very clear that an identifier that can be 
used on one interface (physical or otherwise) MUST also be usable as an 
identifier on any other interface (physical or otherwise) that the 
system has available. Identifiers should be tied to hosts, not to 
interfaces.

On a related note: the SEND CGA stuff mandates using the subnet prefix 
in creating the interface identifier and as such makes it impossible to 
have the same interface identifier in different subnets. I was unable 
to convince them of the error of their ways and apparently there was no 
IETF last call or I missed it so now this stupidity is an RFC. We 
should do our best to make sure there isn't any more of this.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 8 Jun 2004 17:48:33 -0700 (PDT)

> system has available. Identifiers should be tied to hosts, not to 

Seems like we all agree.

> should do our best to make sure there isn't any more of this.

It isn't necessarily a bug to have *interface* identifiers that are
tied to interfaces, even though we want to have stack names or host identifiers
that are not.

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Jun 2004 10:52:20 +0200

Iljitsch,

> have the same interface identifier in different subnets. I was unable to 
> convince them of the error of their ways and apparently there was no 
> IETF last call or I missed it so now this stupidity is an RFC. We should 
> do our best to make sure there isn't any more of this.

(Co-chair hat is OFF.)

I happen to agree with you and disagree with Christian - there should
be a mode in SEND in which the CGA address is generated without including
the (typically /48) prefix which will vary between ISPs when multihomed.

There was a last call, you missed it, and I raised this point in
private email and lost.

For multi6, I believe we should not feel constrained by this. It would
be a fairly simple extension to SEND to allow this, and it might be
a very valuable functionality vs security tradeoff for a multihomed
site that wanted to run SEND.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Jun 2004 12:55:45 +0300

Hi all,

I may be jumping to the middle of this discussion, but
I just wanted to clarify the situation with SEND.
Iljitsch presented his idea of using the lowest 64 bits
as an identifier and we discussed this in the SEND mailing
list. My interpretation of the results of that discussion
is that people were not convinced about the idea. We explained
the need to counteract so called precomputation attacks
in SEND and how the prefix plays an important role in that.
We also talked about the privacy implications. Finally,
I at least wondered what the role of this particular idea
is in terms of multi6 WG; are all the multi6 proposals
going to rely on the same IID or just some of them?

Nevertheless, we also explained to Iljitsch how SEND CGA
addresses can be extended, and how such extensions could
in future be used to create addresses that are based on
CGA but still have the same IID part. Basically, we can
add arbitrary data to the input of the CGA generation,
and this could be used to include all the prefixes of
a host or site in the address. We also explained that
this approach would still have a lot of not-so-trivial
details to worry about, including what to do when prefixes
get deprecated or new ones are added. And due to the way
that the CGAs need to be constructed, we'd need to rev
the current RFC to accommodate for this. However, I
at least am open to such future revisions -- should they
prove necessary.

Finally, I think that I personally agree with Christian
on this issue, at least as far as what the e-mails seem
to say. But I'll try to read Erik's document and come
back with some better comments later.

--Jari

Brian E Carpenter wrote:
>> in creating the interface identifier and as such makes it impossible 
>> to have the same interface identifier in different subnets. I was 
>> unable to convince them of the error of their ways and apparently 
>> there was no IETF last call or I missed it so now this stupidity is an 
>> RFC. We should do our best to make sure there isn't any more of this.
> 
> 
> (Co-chair hat is OFF.)
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 9 Jun 2004 12:09:18 +0200

On 9-jun-04, at 10:52, Brian E Carpenter wrote:

>> On a related note: the SEND CGA stuff mandates using the subnet 
>> prefix in creating the interface identifier and as such makes it 
>> impossible to have the same interface identifier in different 
>> subnets. I was unable to convince them of the error of their ways and 
>> apparently there was no IETF last call or I missed it so now this 
>> stupidity is an RFC. We should do our best to make sure there isn't 
>> any more of this.

> site that wanted to run SEND.

My idea exactly. However, I find it very unfortunate that something 
which has a fairly obvious flaw is published as an RFC. It seems to me 
the IETF is spending inordinate amounts of time on fixing problems that 
shouldn't have gotten that far  in the publication cycle in the first 
place. (I shouldn't have used the word "stupidity", though.)

But let's get our own stuff in order first...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 9 Jun 2004 12:18:28 +0200

On 9-jun-04, at 11:55, Jari Arkko wrote:

> get deprecated or new ones are added.

I think there was some confusion about all of this on the SEND list, as 
this was never the approach I advocated, as this makes everything more 
complex which is never good in general and especially in the area of 
security.

What I wanted was to allow the use of any on-link prefix in the CGA 
generation. So if a link has prefixes A and B, and a host generates a 
CGA interface identifier using prefix A, the host gets to use this same 
interface identifier to create an address with prefix B. I don't see 
how this hurts anyone who isn't interested in this, but it would allow 
switching prefixes and maintaining the lower 64 bits without breaking 
CGA. Still, we don't know if that's something that's required, so the 
whole thing may turn out to be moot anyway when we decide on a multi6 
mechanism.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Jun 2004 13:48:09 +0300

> complex which is never good in general and especially in the area of 

Its possible that me (or others) did not fully understand
what you wanted. Please allow also for the possibility that
us SENDers have studied the security issues and have a
technical reason why the prefix is included. Or that we
have a different opinion than you have about the privacy
issues.

> interface identifier to create an address with prefix B. I don't see how 
> this hurts anyone who isn't interested in this, but it would allow 

Ah, this was indeed different from what I had understood.
Thanks for the clarification.

This proposal is better than the other one, because I think
we could provide a backwards compatible extension to SEND
that allows for this style, by using the CGA Parameters
extension to report the prefix A.

However, I am not convinced -- yet at least -- that the
proposal is secure. I feel uneasy with the thought that
someone (say, the NSA) could construct a precomputed table
of 2^62 CGA addresses for prefix A, and all that would
be needed to take over an address from B::<any IID> would
be to claim that A is "on-link". It does not immediately
follow that the scheme is broken, because we do have
security for prefix advertisements as well. But it is
an additional worry that I, at least, would rather spend
some time analysing rather than adopting it because it
might be needed if solution 7/32 is chosen in multi6 :-)

> whole thing may turn out to be moot anyway when we decide on a multi6 

Yes. My suggestion is that you work it out in multi6 WG first, and
if you come up with a solution that needs an extension or a change
to the SEND specifications, we can talk about it at that time.

By the way, would DHCP work with the same-IID solution?

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 9 Jun 2004 07:18:44 -0700 (PDT)

> Finally,

My understanding is that there is one or a few multi6 proposals that would 
require using the same IID, because those proposals treat that 64 byte
quantity as the identifier for the host.

Other proposals don't care about the IID (at least as a 1st order
approximation); one can envision 2nd order effects related to wanting to
compress the list of a lot of locators assigned to a host and if those locators
have the same 64 bits the compression could take advantage of this.

  Erik