[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heartbeats Straw Poll



On Tue, 8 Aug 2000, Bill Sommerfeld wrote:

> > It is critical that the IP addresses are returned ASAP after the
> > client has disconnected so they can be reused for the next client.
> 
> Is this "critical" as a consequence of excessively tight address
> allocation policies?

Yes.

> 
> If you're billing by "connect time" (a silly concept in a
> connectionless network), bill the client until they either explicitly
> delete the SA or DHCPRELEASE a leased address or until the SA/lease
> expires.  That will give clients an incentive to do a clean
> disconnect.. :-)

I know that there are still times when I don't gracefully disconnect my
dial-in session and I'm pretty savvy about this stuff.  There are alot of people
which are not.  Although, I do agree that money has a funny way of training
people much more quickly.  Regardless, there will be customers that want to bill
for these services and the clients are going to demand accurate accounting since
it will cost them money.  It is no different than the traditional dial-up
infrastructure except as you have noted there isn't the concept of a hardware
connection.  That is why keepalives are important.  In the absence of a "loss of
carrier" mechanism, the protocol must be able to detect a dead peer.

> 
> > > Keep-alives are most important if a dead session is consuming critical 
> > > resources.  What resources are these?  Memory is very cheap these days, 
> > > much cheaper than programmer time to hack IKE.  (To say nothing of WG 
> > > time to consider the changes to IKE...)  Accounting?  Apart from the 
> > > fact that I don't even understand what resource you're accounting for, 
> > 
> > The same resources that we have been tracking for many years now.
> > Duration of the call being of primary importance, 
> 
> That's not a "resource".  The memory used by the SA's is a resource;
> so are any the IP addresses (but if you're allocating ip addresses,
> you must be using some other protocol besides ipsec so that other
> protocol could handle it).  As Steve said, memory is cheap... 

IP addresses are not necessarily cheap.  Filters are also not necessary cheap
since they almost always decrease your pps numbers as more are added.

> 
> > bytes in/out,
> 
> well, if i disappeared, i'm not sending any bytes..

Yes, but just because you are not sending any bytes doesn't mean you are
disconnected.

> 
> > disconnect reason, etc.
> 
> again, that's not a "resource."; it may be interesting to know for
> diagnostic reasons, but it's not a "resource".

I obviously used the wrong word.  My point is that each of these items are
importart information which our customers have come to expect from their well
deployed dial-up networks.  The model really hasn't changed except that they
don't have to manage modems and ISDN resources anymore (now they have to manage
certs :)). They still will need to be able to troubleshoot failures and
determine whether resources need to be added for bandwidth, IP addresses, etc.  
The IT department is still going to want to bill back the departments for their
remote access charges.

> 
> > > you can always record the timestamp of the last packet received on an 
> > > SA.  That's cheap and easy; you're already doing far more processing 
> > > than that per received packet.
> > 
> > Not necessary cheap since it does effect your per-packet code path, but
> > considering how much work goes into each packet for IPsec, I'll give you that
> > one.  However this algorithm is not accurate enough to serve the purposes of
> > accounting or IP address management.
> 
> "not accurate enough"?  It lets you know exactly when the client last
> used its SA... more accurately than missed heartbeats would..

This doesn't give you any information on whether it's viable to teardown the SA
though and relinquish resources back to the system.

> 
> > I would hope the original is destroyed.  This really shouldn't be
> > any different than a new phase 1/2 SA negotiation sequence with a
> > peer which didn't receive the SA delete messages.
> 
> Well, certainly you should send using the newest SA which matches your
> policy.  with respect to reception, at a minimum, I would hope that
> there's a grace period there around rekey time to accept packets sent
> to the old SA which were delayed in transit.  
> 
> I don't see the harm in letting the SA's live until they expire unless
> a DELETE or INITIAL-CONTACT or other affirmative indication that
> they're gone on the other end comes in..

I think the reasons I have listed above make a case for why deleting them before
they expire might be a good thing.  I don't think this should be mandatory
behavior, however I do think a standardized solution which allows this behavior
is worthwhile.

-Skip

> 
> 					- Bill
> 
>
Follow-Ups: References: