Subject: Re: Mini WGLC draft-ietf-multi6-multihoming-threats-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Dec 2004 11:48:21 +0100

Iljitsch van Beijnum wrote:
> On 26-nov-04, at 7:20, Kurt Erik Lindqvist wrote:
> 
>> hereby we start a "mini" Working Group Last Call for the threats
>> document. This concludes on December the 1th 17.00 CET.
> 
> 
> The link doesn't work.

Looks like somebody's mail system wrapped the line
http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-threats-02.txt

> 
> What exactly is the purpose of this last call?

Just a final check before the IESG reaches its decision.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Dec 2004 13:56:53 +0100

> Just a final check before the IESG reaches its decision.

Before publishing this as an RFC, you mean?

Nit on page 6:

                     interface.  Normally an address uniquely identifies
                     an interfaces but there are cases when the same

Page 32:

     - Third trusted party.  A third party establishes that a given

"Identifier" is defined very differently from the use of "ULID" in the 
more recent DT drafts, to the degree that an ULID can't be an 
identifier according to this document's definition.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 1 Dec 2004 09:31:13 -0500

Hi Iljitsch,

At 1:56 PM +0100 12/1/04, Iljitsch van Beijnum wrote:
>"Identifier" is defined very differently from the use of "ULID" in 
>the more recent DT drafts, to the degree that an ULID can't be an 

I think that this is a good point...

I am not sure that all of the threats related to redirection exist 
when you use ULIDs vs. a pure ID/Loc split.

Are there other places in the document where the threat model would 
be different for ULIDs than for IDs that are not also usable as 
locators?

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Dec 2004 16:35:09 +0100

Margaret Wasserman wrote:
> I am not sure that all of the threats related to redirection exist when 
> you use ULIDs vs. a pure ID/Loc split.
> 
> Are there other places in the document where the threat model would be 
> different for ULIDs than for IDs that are not also usable as locators?

Personal opinion: this document is intended to discuss generic threats,
and I think it's a bit unfair to expect it to discuss threats for a
model that hadn't even been invented when the document was almost final.

So I would resolve this by adding a sentence that the specific form of
ULID introduced by the recent design team was not considered and may
(only may) introduce additional threats.

That doesn't let us off the hook of course - ULID threats still need to
be analyzed.

    Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 1 Dec 2004 17:03:14 +0100

> That doesn't let us off the hook of course - ULID threats still need to

I agree with Brian, and I think that analyzing the threats to ULIDs 
would be a priority for the son-of-multi6.

- - kurtis -

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 1 Dec 2004 11:19:25 -0500

>(only may) introduce additional threats.

This works for me...  With the understanding that there will need to 
be some further analysis (perhaps in a different WG) to determine 
how/if the threats for ULIDs differ from those described in this 
document.

Margaret

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Dec 2004 17:23:19 +0100

>> when you use ULIDs vs. a pure ID/Loc split.

Not if we require initial connectivity to happen using the ULID as a 
reachable address/locator.

(But I think we'll want to be able to repair an initially unreachable 
ULID using alternative locators in the future, so we probably shouldn't 
depend on this advantage more than we have to.)

>> be different for ULIDs than for IDs that are not also usable as 

Hard to say. However, the threat model is radically different when HBA 
(or CGA) is in use, so a document that looks at this will be very 
different from this general purpose document. I'm not sure if analyzing 
ULIDs without HBA/CGA is useful, considering the proposed solutions 
that are on the table.

> model that hadn't even been invented when the document was almost 

I agree. My problem with the identifier definition is that an ULID 
doesn't fit this definition, most notably because:

                     The identifiers are not associated with an
                     interface.

My conclusion is that the definition is too strict so it should be 
changed to encompass ULIDs so nothing stands in the way of applying 
this document to solutions that use ULIDs.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Dec 2004 10:50:11 -0800

>     - Third trusted party.  A third party establishes that a given

Thanks.

> more recent DT drafts, to the degree that an ULID can't be an identifier 
> according to this document's definition.

While the definitions are different, I don't see what the conflict is.
Can you elaborate?

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Dec 2004 10:53:33 -0800

> you use ULIDs vs. a pure ID/Loc split.

Which is why there is some text disclaiming this in the 3rd paragraph of 
the introduction.

> different for ULIDs than for IDs that are not also usable as locators?

Do we need to answer this question now and for this document?
My assumption is that any proposed solution would need to do some form 
of security evaluation against the whole list of threats and it might 
very well be that some threats don't apply at all because there is no 
separate ID name space. But we can defer that question until later I 
think, and keep this document more general.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 01 Dec 2004 10:58:45 -0800

Iljitsch van Beijnum wrote:

> changed to encompass ULIDs so nothing stands in the way of applying this 
> document to solutions that use ULIDs.

Ignore my mail asking for clarifications; I now see the issue.

I think we should reword the above sentence to say that the identifiers 
are not tightly bound to an interface; to provide communication 
survivability when one interface fails the identifiers must be usable on 
any interface.

(I welcome suggestions for how to make that text shorter.)

    Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Dec 2004 20:54:54 +0100

On 1-dec-04, at 19:58, Erik Nordmark wrote:

> I think we should reword the above sentence to say that the 
> identifiers are not tightly bound to an interface; to provide 
> communication survivability when one interface fails the identifiers 
> must be usable on any interface.

> (I welcome suggestions for how to make that text shorter.)

An identifier continues to function regardless of the state of any one 
interface.