headers
Mohan Parthasarathy | 1 Dec 03:11
Picon
Favicon

Re: mumti6dt drafts as WG drafts?

Brian,

So, the solution architecture document will come later on based on the
WG documents i guess. What is the rationale behind having it as
separate documents still ? Having read some of them, i felt that it might be
good to have some of them at least merged to understand the solution
better. For example, the first three below (shim, hba and func) can be
merged. 

-mohan

> In accordance with the consensus to proceed with the direction
> proposed by the design team, does anyone object to the next versions
> of the following drafts being formally adopted as WG drafts?
> This would mean they have names like draft-ietf-multi6-*
> 
> Please let us know this week if you object, and why.
> 
>      Multihoming Level 3 Shim Approach
>      (draft-nordmark-multi6dt-shim-00.txt)
>      Hash Based Addresses (HBA)
>      (draft-bagnulo-multi6dt-hba-00.txt)
>      Functional decomposition of the M6 protocol
>      (draft-bagnulo-multi6dt-functional-dec-00.txt)
>      Failure Detection and Locator Selection in Multi6
>      (draft-arkko-multi6dt-failure-detection-00.txt)
>      Multi6 Application Referral Issues
>      (draft-nordmark-multi6dt-refer-00.txt)
> 
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brian E Carpenter | 1 Dec 11:48
Picon
Favicon

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

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
Permalink | Reply | 10 comments |
headers
Brian E Carpenter | 1 Dec 11:52
Picon
Favicon

Re: mumti6dt drafts as WG drafts?

Well, yes, the solution architecture draft is intended to give the
overview.

It's quite likely that when the various pieces have stabilized,
they should be combined into a more complete document. But that is
really a question for whichever WG is tasked with doing the complete
specification, so it is not a question for multi6 today. The idea now
was to get the existing drafts into a good state individually.

     Brian

Mohan Parthasarathy wrote:
> Brian,
> 
> So, the solution architecture document will come later on based on the
> WG documents i guess. What is the rationale behind having it as
> separate documents still ? Having read some of them, i felt that it might be
> good to have some of them at least merged to understand the solution
> better. For example, the first three below (shim, hba and func) can be
> merged. 
> 
> -mohan
> 
> 
>>In accordance with the consensus to proceed with the direction
>>proposed by the design team, does anyone object to the next versions
>>of the following drafts being formally adopted as WG drafts?
>>This would mean they have names like draft-ietf-multi6-*
>>
>>Please let us know this week if you object, and why.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 1 Dec 11:56
Picon
Favicon

Re: Draft multi6 minutes

Erik Nordmark wrote:
> Tim Shepard wrote:
...
>> If security is not needed, then perhaps we don't even need to use the
>> HBA scheme.  If security is needed, then perhaps this scheme isn't
>> much better than using some public key cryptography.
> 
> 
> We know that security is needed. full stop.

Also, whether HBA is better or worse than PK crypto isn't quite the
point for me (chair hat off). As long as HBA is strong enough, the
fact that it doesn't require any kind of PKI is an enormous benefit.
Multihoming needs to work between any arbitrary pair of hosts, and doing
that without PKI is an enormous win.

     Brian
Permalink | Reply | 1 comment |
headers
Iljitsch van Beijnum | 1 Dec 13:56
Favicon

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

On 1-dec-04, at 11:48, Brian E Carpenter wrote:

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

> 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.
Permalink | Reply | 9 comments |
headers
Margaret Wasserman | 1 Dec 15:31
Favicon

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


Hi Iljitsch,

At 1:56 PM +0100 12/1/04, Iljitsch van Beijnum wrote:
>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.

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
Permalink | Reply | 7 comments |
headers
Brian E Carpenter | 1 Dec 16:35
Picon
Favicon

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

Margaret Wasserman wrote:
> 
> Hi Iljitsch,
> 
> At 1:56 PM +0100 12/1/04, Iljitsch van Beijnum wrote:
> 
>> 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.
> 
> 
> 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?

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.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Kurt Erik Lindqvist | 1 Dec 17:03
Picon

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


On 2004-12-01, at 16.35, Brian E Carpenter wrote:

> Margaret Wasserman wrote:
>> Hi Iljitsch,
>> At 1:56 PM +0100 12/1/04, Iljitsch van Beijnum wrote:
>>> 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.
>> 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?
>
> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Iljitsch van Beijnum | 1 Dec 17:23
Favicon

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

On 1-dec-04, at 16:35, Brian E Carpenter 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 
>>> identifier according to this document's definition.

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

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

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

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.

> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Margaret Wasserman | 1 Dec 17:19
Favicon

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

At 4:35 PM +0100 12/1/04, Brian E Carpenter wrote:
>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.

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
Permalink | Reply | 0 comments |

Gmane