headers
Iljitsch van Beijnum | 1 Feb 22:02
Favicon

HIP draft

On 25-jan-04, at 16:59, Brian E Carpenter wrote:

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-00.txt

Ok, I'm missing two things here:

1. Failover. The draft says the wg should come up with this. Ok.

2. What mechanism makes it possible for unmodified ULPs to set up 
connections to HIP-capable destinations? I would expect either the 
application to be modified so it knows to ask for the HIP DNS RR, or 
there must be some shady resolver hacks that trick the app and TCP (or 
other ULPs) so they think they're dealing with a regular IPv6 address 
but in effect they're using HIP identifiers and the associated IP 
addresses are recovered at the HIP layer.

And would it be possible to implement HIP in middleboxes so that 
unmodified hosts can talk to HIP boxes?
Permalink | Reply | 3 comments |
headers
Brian E Carpenter | 2 Feb 10:30
Picon
Favicon

Re: Evaluating multiaddressing proposals

Dave Crocker wrote as below, but it bounced due to a list subscription issue.

I see these comments as input to Eliot's draft.

   Brian
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

*** I will be on vacation February 3-25, 2004 ***

> 
> Folks,
> 
> I put together a list of categories that seem interesting for
> evaluating different multiaddressing proposals.
> 
> No doubt the list is terrible. That's ok. Think of what follows as an
> excuse for everyone to fix it:
> 
> Features
>         Multiaddressing
>                        Multihoming, mobility, both
>         Infrastructure
>                       None, sometimes, always
>         IP version(s)
>         Identifier
>                   Registered vs. ephemeral
>         Rendezvous
>                   Creating the association
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jukka Ylitalo | 2 Feb 12:30

Re: New multi6 draft: WIMP

Hi Marcelo,

Thanks for reading through our draft.

marcelo bagnulo wrote:

>Hi Jukka,
>
>I am trying to understand your draft, and i have some questions about some
>points that you perhaps can help me with.
>
>  
>
You have pointed out several important issues that need clarification. I 
already
apologize my long email.

>1. About the Context establishement exchange (section 3.4)
>I fail to see what you mean when you state that the responder remains
>stateless.
>I mean, the responder has to generate the temrporary hash chain. This hash
>chain has to be specific to this particular host pair context, right? (this
>is what it is stated in section 3.3 about generating reverse hash chains)
>So, this means that when the responder receives an INIT message it has to
>generate a new hash chain (or reserve a pre computed hash chain for this
>initiated context establishement), would this be correct?. If so, the
>responder has to at least store a state that is that this hash chain is
>reserved and cannot be used for a future INIT, right?
>
>
(Continue reading)

Permalink | Reply | 15 comments |
headers
Cedric de Launois | 2 Feb 14:58
Picon

RE: Host Centric Multi-Homing

> I have already updated the draft with some of your comments, you can check
> it at the same location:
> 
> http://www.it.uc3m.es/marcelo/draft-huitema-multi6-hosts-02.txt

Thanks for the changes.

Here are some other comments. Yes, I like your draft ;)

6.4 Solution 4: Host based exit path selection + source address based
    routing

 "Required modifications: implementation of the path discovery
  mechanism"

 What is exactly the path discovery mechanism ? Is it the path failure
 detection described 5.1.2.2.2 ? You should perhaps refer to the
 appropriate section where the mechanism is described.

7. Proposed solution
7.1 Multihoming solutions for small sites

I don't see clearly which solution (from the ones you describe in
section 6) you recommend.
In fact, you are recommending 2 (optimized) solutions for small sites :

- Host based exit path selection + site exit discovery
- Host based exit path selection + source address based routing

Some mechanisms you discuss in section 7.1 apply to the first solution
(Continue reading)

Permalink | Reply | 1 comment |
headers
Masataka Ohta | 2 Feb 17:14
Picon

Re: Evaluating multiaddressing proposals

Brian E Carpenter wrote:

> Dave Crocker wrote as below, but it bounced due to a list subscription issue.
> 
> I see these comments as input to Eliot's draft.

The only thing I should say is that there is absolutely
no evaluation nor evalutation criteria.

							Masataka Ohta
Permalink | Reply | 0 comments |
headers
marcelo bagnulo | 2 Feb 17:30
Picon

RE: New multi6 draft: WIMP

Hi Jukka,

thanks for this detailed explanation, more below...

[...]

> [Do not hesitate to ask more questions about this, if I my answer was
> not clear enough.]

I think i understand that part, i see now why it is stateless.

>
> >If so, wouldn't this imply that an attacker sending INIT messages could
> >force the responder to gnerate hash chains, sort of DoS attack?

[...]

> A short hash chain generation is a quite fast operation compared to
> signature calculation.

why do you compare it with the processing required to perform a signature
calculation?

I mean if i were an attacker, i would do the following:

The goal of the DoS attack is to consume the processing power by soliciting
the victim to produce (useless) hash chains.

So, the attacker generates a random number as an ID(I) and also a
challenge(I) and then simply generate a random string which length is the
(Continue reading)

Permalink | Reply | 4 comments |
headers
marcelo bagnulo | 2 Feb 17:50
Picon

RE: HIP draft

> 2. What mechanism makes it possible for unmodified ULPs to set up
> connections to HIP-capable destinations? I would expect either the
> application to be modified so it knows to ask for the HIP DNS RR, or
> there must be some shady resolver hacks that trick the app and TCP (or
> other ULPs) so they think they're dealing with a regular IPv6 address
> but in effect they're using HIP identifiers and the associated IP
> addresses are recovered at the HIP layer.

My understanding is that the last option is proposed.

>
> And would it be possible to implement HIP in middleboxes so that
> unmodified hosts can talk to HIP boxes?
>

I think so. But the doc states that this will be detailed in another
document.

However, i haven't been able to find it as a item neither in the pwg carter
nor in the prg charter. Shouldn't this be explicitely included?

Regards, marcelo
Permalink | Reply | 2 comments |
headers
marcelo bagnulo | 2 Feb 18:50
Picon

RE: Host Centric Multi-Homing

Hi Cedric,

thank you very much for your feedback and your interest

>
> 6.4 Solution 4: Host based exit path selection + source address based
>     routing
>
>  "Required modifications: implementation of the path discovery
>   mechanism"
>
>  What is exactly the path discovery mechanism ? Is it the path failure
>  detection described 5.1.2.2.2 ?

Yes

> You should perhaps refer to the
>  appropriate section where the mechanism is described.
>

I will do that

> 7. Proposed solution
> 7.1 Multihoming solutions for small sites
>
> I don't see clearly which solution (from the ones you describe in
> section 6) you recommend.

Yes, this is not clear
(Continue reading)

Permalink | Reply | 0 comments |
headers
Armando L. Caro Jr. | 2 Feb 18:54

proposal list

Is anyone maintaining a list of all the proposals and their URLs? I am
trying to get up to speed on this list and want to go through all the
proposals.

Thanks.

~armando

0--                                              --0
| Armando L. Caro Jr.  |  Protocol Engineering Lab |
| www.armandocaro.net  |    University of Delaware |
0--                                              --0
Permalink | Reply | 1 comment |
headers
Internet-Drafts | 2 Feb 22:02
Picon
Favicon

I-D ACTION:draft-coene-multi6-sctp-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Multihoming: the SCTP solution
	Author(s)	: L. Coene
	Filename	: draft-coene-multi6-sctp-00.txt
	Pages		: 14
	Date		: 2004-2-2
	
This document describes the multhoming solution used in SCTP. It
   tries to answer the questions posed in 'Things MULTI6  developers
   should think about' [1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-coene-multi6-sctp-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-coene-multi6-sctp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane