RE: RE: issue 34 -- ESP vs. IKE based NAT reboot detection
"Stephane Beaulieu (stephane)" <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <13E3DA8B48E17D4C96D261A36A23FCD685EC8C@xmb-rtp-208.amer.cisco.com> |
Tero, Pasi, Not really. DPD's are only sent *if* one suspects that the peer is no longer receiving pkts. What we've seen in the real world is that in a span of a 24 hour VPN RA connection, you'll probably only see about 20-100 DPD messages (which are usually clustered in groups during high web-usage times). So, DPDs are not periodic. Having said that, I don't see why probes would need to be periodic either. If you suspect the pkts aren't getting to your peer, then send the DPD/mobike probe. Otherwise, don't send anything. If we can agree on this, then I'm OK with probes. Stephane. > -----Original Message----- > From: Tero Kivinen [mailto:[email protected]] > Sent: Thursday, September 01, 2005 9:08 AM > To: Stephane Beaulieu (stephane) > Cc: Jari Arkko; [email protected]; Mohan Parthasarathy; > [email protected] > Subject: RE: [Mobike] RE: issue 34 -- ESP vs. IKE based NAT > reboot detection > > Stephane Beaulieu \(stephane\) writes: > > I would prefer to avoid sending periodic probes (option 3). > > We are sending them anyways if there is no traffic (IKE SA > dead peer detection). The difference is that in option 1 > those probes are only used to detect if the other peer is > alive, and in option 3 they also make sure that the other end > the correct NAT-T mapping in addition to test that the other > peer is alive. The amount and timers for those packets should > be same, but Pasi was little bit concerned that some > adminstrators might want to configure the timers shorter in > case we select option 3 to allow faster recovery of lost NAT > mappings. I myself thing that this is such corner case that I > do not think anybody will configure the timers shorter > because of that. > > The option 3 packets will be few bytes bigger than the option > 1 packets, but actually the size difference is lost in the > padding (at least for AES cipher). Both of them are small, > i.e. about 100 bytes (ip 20 + udp 8 + ike 28 + encr header 4 > + iv 16 + empty or 8 byte notify plus padding 16 + 12). > > In addition to that IKE SA dead peer detection payloads, > there is the normal NAT-T keepalive packets going on, which > are again same in both option 1 and 3. > -- > [email protected] >