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

Re: Heartbeats Straw Poll



In message <Pine.GSO.4.10.10008081353100.13640-100000@uzura.cisco.com>, Skip Bo
oth writes:

>
>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 manag
>e
>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 thei
>r
>remote access charges.

Many customers "expect" things because their old charge forms from 
their modem pools have blanks for them.  It doesn't mean that they're 
real.  (I used to have to pay for cards punched...)

Bandwidth is a resource, as are IP addresses, and I agree that some 
folks will want (and maybe even need, though that's more debatable) to 
charge back for them.  For bandwidth, though, one can count the bytes 
coming in; if they stop, they stop, regardless of whether or not 
there's an SA.  For addresses, why not just use DHCP lease time?
>
>> 
>> > > 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 t
>hat
>> > 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 S
>A
>though and relinquish resources back to the system.

How is it any different?  If I can get through to the remote site at 
all, I can't give back the resources.  Doing something at the IKE level 
says the same thing.  *Maybe* something is wedged with IKE, and I can 
get payload through but the IKE process isn't responding.  But to me, 
that sounds like a great reason to keep the connection up; after all, 
useful stuff is getting through.



		--Steve Bellovin