Subject: RE: [Mobike] Re: Lack of packets from other end

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 21 Dec 2004 13:44:50 +0100

hi bora, 

please see my comment below: 

> > Tschofenig Hannes wrote:
> > | hi all,
> > |
> > | i guess we can close issue # 16:
> > | "Can the protocol recover from situations where the only sign of
> > problems is
> > | lack of packets from the other end?"
> > | http://www.vpnc.org/ietf-mobike/issue16.txt
> > 
> > Internet paths that are silent aren't problems, IMO. 
> They're just idle 
> > network paths.
> > 
> > This sounds like a job for a link layer, and I don't think mobike 
> > needs to be a link layer.
> > 
> > Joe
> 
> I agree with Joe here. There are legitimate situations where 
> there may be no packets from the other end for a long period 
> of time. We have DPD to detect a dead peer. If a peer moves 
> from one IP addr to another without notifying the security 
> gateway, I don't think it is the SG's job to detect and 
> recover from this.

please note that we are addressing the issue of address changes for ikev2
peers only. we are not talking about fixing problems for entities which do
not interact using ike. at the last ietf pasi presented a nice slide which
showed the large number of protocols and entities involved in a network. he
showed us that we are only addressing a subset of the problems and i agree
with him. 

ciao
hannes

> 
> Regards,
> 
> Bora
> _______________________________________________
> Mobike mailing list
> [email-masked]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Dec 2004 14:56:19 +0200

Tschofenig Hannes wrote:

> please note that we are addressing the issue of address changes for ikev2 peers only. we are not talking about fixing problems for entities which do not interact using ike. at the last ietf pasi presented a nice slide which showed the large number of protocols and entities involved in a network. he showed us that we are only addressing a subset of the problems and i agree with him.

> gateway, I don't think it is the SG's job to detect and 

In fact, it would be *impossible* for the SG to recover
from it, because it has no other address for the peer in the
case that you mention above. The only question
we have on the table is whether an indication from the
DPD causes a change in the currently preferred address,
*if* the peer has previously indicated that it has several
addresses. Past practise (SCTP) and ongoing designs (HIP,
MULTI6) all have the approach where the preferred address
would be changed in a situation like that.

(Another question would be whether the client or the SG
needs is responsible for detecting and correcting a choice.
I don't want to open that discussion yet, but in general
I like the client or the initiator to be responsible for
as much as possible, unless protocol symmetry requires
otherwise.)

--Jari

---

From: "Bora Akyol" <[email-masked]>
Date: Tue, 21 Dec 2004 19:24:57 -0800

> 
> In fact, it would be *impossible* for the SG to recover from 
> it, because it has no other address for the peer in the case 
> that you mention above. The only question we have on the 
> table is whether an indication from the DPD causes a change 
> in the currently preferred address,
> (Another question would be whether the client or the SG needs 
> is responsible for detecting and correcting a choice.
> I don't want to open that discussion yet, but in general I 
> like the client or the initiator to be responsible for as 
> much as possible, unless protocol symmetry requires
> otherwise.)
> 
> --Jari
> 
> 

Jari, I think we are in agreement, I would like to keep
the SG as simple as possible. It needs to have enough smarts to clean-up
garbage state, but if the client has switched to an alternate address,
I think it should __really__ let the SG know. We may need some
logic to do Make-before-break type switch like is common on cell phone
networks.

Thanks

Bora

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 21 Dec 2004 22:36:40 -0500

On Tue, 2004-12-21 at 22:24, Bora Akyol wrote:
>  We may need some

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

---

From: "Bora Akyol" <[email-masked]>
Date: Tue, 21 Dec 2004 19:55:37 -0800

> -----Original Message-----
> From: Bill Sommerfeld [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 7:37 PM
> To: Bora Akyol
> Cc: [email-masked]; 'Tschofenig Hannes'; [email-masked]
> Subject: RE: [Mobike] Re: Lack of packets from other end
> 
> that's the entire point of attaching sctp-like multiple 
> addresses to IKE and IPsec SA's.
> 
> 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