RE: Re: Lack of packets from other end

 

> -----Original Message-----
> From: Bill Sommerfeld [mailto:[email protected]] 
> Sent: Tuesday, December 21, 2004 7:37 PM
> To: Bora Akyol
> Cc: [email protected]; 'Tschofenig Hannes'; [email protected]
> Subject: RE: [Mobike] Re: Lack of packets from other end
> 
> On Tue, 2004-12-21 at 22:24, Bora Akyol wrote:
> >  We may need some
> > logic to do Make-before-break type switch like is common on 
> cell phone 
> > networks.
> 
> that's the entire point of attaching sctp-like multiple 
> addresses to IKE and IPsec SA's.
> 
> anyhow, to respond to an earlier question of yours:
> 
>  - if the SG's peer has given us multiple addresses
>  - and the SG is also a stateful firewall of some sort
> 
> then it should be capable of noticing that traffic to the peer
> *should* have provoked a response (e.g., any non-pure-ACK TCP
> segment) but *didn't*.
> 
> if the SG is not acting as a stateful firewall I wouldn't 
> expect it to do this sort of thing.  decouple the source of 
> the hints that all is not well from the action taken when you 
> notice all is not well, and leave which hints to use 
> open-ended for now..

Bill

While I see your point, IMHO, I think we should keep the functionality
required
on both the SG and the client as simple as possible for now.
The fact that the client may have multiple addresses is __nice__ but
realistically, how many of the enterprise, home, or public Internet access
networks
can guarantee that the client will have the same address for an extended
period
of time. Yes, this is doable via DHCP (and other means like static
addresses), 
but it remains an assumption. By the way, clearly I don't want to exclude
IPv4
and IPv6 coexisting for the same client. This is one case that (IMHO) would
be
really nice to support (although it may play funny games with the SP
implementation).

I believe the existing version of the draft defines several workable
scenarios,
I think we should find the minimum required functionality, and work towards
that as the goal for v1 of MOBIKE.

With generic goals I would add as:

1) Scalable (say up to 1000000 clients per node)
2) Brain-dead simple to implement with as little as possible "optional",
"SHALL", "MAY"
wording as possible. As little exceptions, omitted functionality etc for
special kinds of devices.
3) Supporting the minimal required scenario as I eluded to below.

I think once there is agreement (and I acknowledge that I am a latecomer to
the process
and apologize for it here) on the minimum acceptable set of requirements, we
can
quickly move towards the solutions.

Thank you for your comments,

Bora