headers
Khaled Masmoudi | 3 Apr 2005 20:12
Picon

ASWN 2005 CFP - extended deadline : April 11th

[My sincere apologies if you receive multiple copies of this CFP]

CALL FOR PAPERS

------------------------------------------------------
ASWN 2005
5th Workshop on Applications and Services in Wireless Networks

Maison de la Chimie
28 rue Saint Dominique- 75007, Paris - FRANCE
June 29th - July 1st, 2005
--------------------------------------------------------
ASWN 2005 is the fifth workshop on Applications and
Services in Wireless Networks. The workshop
addresses the challenges and advances in future
wireless applications and services that span all wireless
architectures and technologies, such as cellular, WLAN,
WPAN, ad hoc, and sensor networks. The format of the
workshop is based on three-day single-track sessions,
with presentations of invited and regular papers from
academia and industry. This year's special theme is the
impact of newly emerging technologies, such as sensor
networks, embedded systems, systems on chip, and
nanotechnologies, on wireless applications and
services. The workshop solicits original technical paper
contributions in the scope of the workshop, describing
theoretical and practical recent results or developments.
In particular, we seek submissions that present
advances in open programmable and directory enabled
networking, overlay networks, user-centric open service
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tero Kivinen | 4 Apr 2005 12:57
Picon
Picon
Favicon

issue 11 -- window size

Jari Arkko writes:
> 
> This issue is about the window size. Mobike needs to be able to
> send multiple messages, given that a regular IKEv2 exchange
> may be in progress when we suddenly change our IP address.
> The question is whether we should expect IKEv2 implementations
> to support window size greater than 1, or if Mobike's own
> exchanges are in some sense outside the regular IKEv2
> window (as proposed in Pasi's MOPO protocol).
> 
> The background information we got in the meeting was that
> in the IKEv2 bakeoff many implementors did not have
> support for larger than 1 window sizes.
> 
> So we could either require a larger window size or do MOBIKE
> exchanges outside the window. I did not sense a conclusion
> in the meeting about this, but on the other hand I'm not sure
> if people care about this issue very deeply. For the purpose
> of making progress, let me propose one approach. If the
> decision was "do it outside the window", would people have
> problems with that?

There is also one other option, i.e. the way my original protocol
proposal did it, i.e. every IKE packet can be used to test the paths.
If you add also so that every IKE packet also includes the information
needed to do mobility that solves the problem with window size 1.

I.e. if mobike needs n payload for its processing, you add those n
payloads to all IKE packets, and then when you are retransmitting the
IKE packet you simply also use that packet to do path finding, i.e.
(Continue reading)

Permalink | Reply | 20 comments |
headers
Jari Arkko | 4 Apr 2005 14:51

Re: issue 11 -- window size

Hi Tero,

This is interesting, I think it looks attractive!

(So what exactly would "information needed to
do mobility and path testing" constitute? Presumably, one of
the things that we would probably need is a NAT-D payload.
Would this mean that if we have send request X and later
realize that we don't get a response and have to retransmit
on another, new interface, we resubmit X exactly as-is?
Or can we add "mobility data", such as NAT-D payload?
Or perhaps "mobility data" is simply the source address
and NAT-D payloads are always included...?)

--Jari
Permalink | Reply | 15 comments |
headers
Tero Kivinen | 5 Apr 2005 09:58
Picon
Picon
Favicon

Re: issue 11 -- window size

Jari Arkko writes:
> (So what exactly would "information needed to
> do mobility and path testing" constitute?

Depends about the answers to issue 3...

> Presumably, one of the things that we would probably need is a NAT-D
> payload.

Not necessarely, in the simplies form it would be simply outer IP
addresses and ports.

> Would this mean that if we have send request X and later
> realize that we don't get a response and have to retransmit
> on another, new interface, we resubmit X exactly as-is?

Yes. The packet must be resubmitted as-is, only IP-addresses and ports
can change. There responder might be taking HASH of the packet when
processing it and store the reply packet, and when he sees the
retransmission he must be able to match the hash of the previous
retransmission to this new one. 

> Or can we add "mobility data", such as NAT-D payload?

No, we cannot add those. 

> Or perhaps "mobility data" is simply the source address
> and NAT-D payloads are always included...?)

That would be one option.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Francis Dupont | 5 Apr 2005 10:22
Picon
Picon

Re: issues 18, 15, 6 -- return routability

 In your previous mail you wrote:

     - If the specific IP address can be found in the peer's certificate, 
   you can skip the test

=> I maintain my proposal to change this into "if the specific IP address
is already authorized, you can skip the test".
This is more general (as there can be other ways to authorized an address)
and more accurate (so it should answer Vijay's concern).

Regards

Francis.Dupont <at> enst-bretagne.fr
Permalink | Reply | 4 comments |
headers
Tero Kivinen | 5 Apr 2005 11:34
Picon
Picon
Favicon

Re: issues 18, 15, 6 -- return routability

Francis Dupont writes:
>  In your previous mail you wrote:
> 
>      - If the specific IP address can be found in the peer's certificate, 
>    you can skip the test
>    
> => I maintain my proposal to change this into "if the specific IP address
> is already authorized, you can skip the test".
> This is more general (as there can be other ways to authorized an address)
> and more accurate (so it should answer Vijay's concern).

Agree on Francis on this. We do not need to specify how it is already
authorized. Certificate is one way, typed in to the configuration, or
authorized by the dnssec information are others.

Most of the cases where the IP-address is already authorized are the
cases where there is multihoming SGW so all IP-addresses are already
known when the machine is installed, but mobike is simply used because
of the multihoming aspect to select which of those IP-addresses are
used. 
--

-- 
kivinen <at> safenet-inc.com
Permalink | Reply | 2 comments |
headers
James Kempf | 5 Apr 2005 18:00

Re: issues 18, 15, 6 -- return routability

How about CGA?

            jak

----- Original Message ----- 
From: "Tero Kivinen" <kivinen <at> iki.fi>
To: "Francis Dupont" <Francis.Dupont <at> enst-bretagne.fr>
Cc: <mobike <at> machshav.com>; "Jari Arkko" <jari.arkko <at> piuha.net>
Sent: Tuesday, April 05, 2005 2:34 AM
Subject: Re: [Mobike] issues 18, 15, 6 -- return routability

> Francis Dupont writes:
> >  In your previous mail you wrote:
> >
> >      - If the specific IP address can be found in the peer's
certificate,
> >    you can skip the test
> >
> > => I maintain my proposal to change this into "if the specific IP
address
> > is already authorized, you can skip the test".
> > This is more general (as there can be other ways to authorized an
address)
> > and more accurate (so it should answer Vijay's concern).
>
> Agree on Francis on this. We do not need to specify how it is already
> authorized. Certificate is one way, typed in to the configuration, or
> authorized by the dnssec information are others.
>
> Most of the cases where the IP-address is already authorized are the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mohan Parthasarathy | 6 Apr 2005 02:41
Picon
Favicon

Re: issue 11 -- window size

Tero,

Some questions/clarifications..

> 
> Now if we want to see why we cannot modify the packet between
> retranmissions take the next case where we have also shorter temporary
> failures or one way connections.
> 
> Connection between A1 and B2 breaks down (A1 address does not work).
> Host A notices that he hasn't received anything and starts DPD.
> 
> (A1, B2, 57) DPD -> (dropped)
> (A1, B2, 57) DPD -> (dropped)
> (A1, B2, 57) DPD -> (dropped)
> 
> Host A notices that he is not getting anything back so he starts
> searching for the working address pair:
> 
> (A2, B1, 57) DPD ->
> 
> Host B gets the packet, and replies to it, but the
> packet is dropped because of some other reason (one
> way path etc). Host B has now calculated HASH(DPD) and
> stored it in his incoming window for message id 57,
> and also has stored the "DPD reply" to be sent back in
> case the message id 57 (HASH(DPD)) is retranmitted.
> 
> (drop) <- (B1, A2, 57R) DPD reply
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Stephane Beaulieu | 6 Apr 2005 15:02
Picon
Favicon

RE: issue 11 -- window size

Hi Tero,

> 
> There is also one other option, i.e. the way my original 
> protocol proposal did it, i.e. every IKE packet can be used 
> to test the paths.
> If you add also so that every IKE packet also includes the 
> information needed to do mobility that solves the problem 
> with window size 1.
> 
> I.e. if mobike needs n payload for its processing, you add 
> those n payloads to all IKE packets, and then when you are 
> retransmitting the IKE packet you simply also use that packet 
> to do path finding, i.e.
> change the source and destination addresses but keep the packet same.
> The responder will reply to reversed addresses, and after 
> that IKE exchange both ends know that the path has changed, 
> and can take appropriate actions (either automatically or 
> manually by sending another exchange).

So, if you have two peers

PeerA(A1,A2) PeerB(B1,B2) which are using A1<->B1 for the initial
connection.

Given the following sequence of events
- Window Size = 1

A1 --> B1 (CREATE_CHILD_SA request)
Interface A1 goes down
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stephane Beaulieu | 6 Apr 2005 16:25
Picon
Favicon

RE: [WARNING: A/V UNSCANNABLE] RE: issue 11 -- window size

Sorry, I didn't notice your other post until I sent this.  Your follow up
post answers my questions.

> 
> Hi Tero,
> 
> > 
> > There is also one other option, i.e. the way my original protocol 
> > proposal did it, i.e. every IKE packet can be used to test 
> the paths.
> > If you add also so that every IKE packet also includes the 
> information 
> > needed to do mobility that solves the problem with window size 1.
> > 
> > I.e. if mobike needs n payload for its processing, you add those n 
> > payloads to all IKE packets, and then when you are 
> retransmitting the 
> > IKE packet you simply also use that packet to do path finding, i.e.
> > change the source and destination addresses but keep the 
> packet same.
> > The responder will reply to reversed addresses, and after that IKE 
> > exchange both ends know that the path has changed, and can take 
> > appropriate actions (either automatically or manually by sending 
> > another exchange).
> 
> So, if you have two peers
> 
> PeerA(A1,A2) PeerB(B1,B2) which are using A1<->B1 for the 
> initial connection.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane