Scott C Moonen writes:
> > As the host is sending traffic it will immediately notice when it is
> > not getting ACKs back from the GW, i.e. when the traffic gets
> > unidirectional, and again it can start fixing situation at that
> > point.
>
> But Tero, that process can take several minutes. Fir
m: Tero Kivinen
To: David Wierbowski/Endicott/i...@ibmus
Cc: ipsec@ietf.org
Date: 10/06/2010 09:40 AM
Subject:Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00
Sent by:ipsec-boun...@ietf.org
David Wierbowski writes:
> Tero writes:
> >David Wierbowski wri
David Wierbowski writes:
> Tero writes:
> >David Wierbowski writes:
> >> Tero writes:
> >> >I do not consider very open protocols which allow all kind of things
> >> >"just for fun" and "in case we someday get scenario which can use it"
> >> >as good thing.
> >>
> >> I do not think we are allowing
Tero writes:
>David Wierbowski writes:
>> Tero writes:
>> >I do not consider very open protocols which allow all kind of things
>> >"just for fun" and "in case we someday get scenario which can use it"
>> >as good thing.
>>
>> I do not think we are allowing the initiator and responder to
>> be both
David Wierbowski writes:
> Tero writes:
> >I do not consider very open protocols which allow all kind of things
> >"just for fun" and "in case we someday get scenario which can use it"
> >as good thing.
>
> I do not think we are allowing the initiator and responder to
> be both a taker and a maker
Tero writes:
>I do not consider very open protocols which allow all kind of things
>"just for fun" and "in case we someday get scenario which can use it"
>as good thing.
I do not think we are allowing the initiator and responder to
be both a taker and a maker just for fun. There are cases where
e
Yaron Sheffer writes:
> It seems to me we are adding architectural assumptions,
Not really adding architectural assumption, but just explaining that
in those cases we do not need QCD, as we have more efficient already
standardized ways to handle the situation.
> just to gain a relatively minor s
Hi Tero,
It seems to me we are adding architectural assumptions, just to gain a
relatively minor simplification of the protocol. Not a very good trade-off.
Thanks,
Yaron
On 09/13/2010 03:43 PM, Tero Kivinen wrote:
Yaron Sheffer writes:
you are assuming you can always map an IP addre
Yaron Sheffer writes:
> you are assuming you can always map an IP address (of the incoming ESP)
> into the peer's identity. This is often possible, but not always. For
> example, if you're using round-robin DNS to look up the B peer, or if
> IKE Redirect was used.
Yes, that is the case if you h
Hi Tero,
you are assuming you can always map an IP address (of the incoming ESP)
into the peer's identity. This is often possible, but not always. For
example, if you're using round-robin DNS to look up the B peer, or if
IKE Redirect was used.
Thanks,
Yaron
On 09/13/2010 12:51 PM, T
Yaron Sheffer writes:
> I agree with Scott's position. In the case of site-to-site VPN, where
> SAs are NOT set up by configuration, but rather triggered by traffic,
> you can have a tunnel triggered by traffic from A to B, but later mostly
> used in the opposite direction. This would benefit fr
David Wierbowski writes:
> I disagree with this "simplification." Tero's logic is that this does make
> sense in some cases (e.g. his case), so let's disallow it. As Scott Moonen
> pointed out, there are cases where it is perfectly valid to expect either
> endpoint to send the next packet and cas
I agree with Scott's position. In the case of site-to-site VPN, where
SAs are NOT set up by configuration, but rather triggered by traffic,
you can have a tunnel triggered by traffic from A to B, but later mostly
used in the opposite direction. This would benefit from allowing the
original resp
At 5:29 PM +0300 9/10/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> >True, we need some other term for it. Something like the original
>> >IKE_SA_INIT initiator or the party initiating the initial connection
>> >(i.e. triggering). Or simply say that the QCD_TOKENs in INFORMATIONAL
>> >exchanges
Tero writes:
>Paul Hoffman writes:
>> >True, we need some other term for it. Something like the original
>> >IKE_SA_INIT initiator or the party initiating the initial connection
>> >(i.e. triggering). Or simply say that the QCD_TOKENs in INFORMATIONAL
>> >exchanges and rekeys can only be sent by th
Paul Hoffman writes:
> >True, we need some other term for it. Something like the original
> >IKE_SA_INIT initiator or the party initiating the initial connection
> >(i.e. triggering). Or simply say that the QCD_TOKENs in INFORMATIONAL
> >exchanges and rekeys can only be sent by the peer who origina
At 11:01 AM +0300 9/9/10, Tero Kivinen wrote:
>Scott C Moonen writes:
>> > I was thinking about the original initiator, not the exchange
>> > initiator.
>>
>> Ok, but this then imposes an awkward new requirement to remember the
>> "original original initiator," as it were. Today the initiator of
Scott C Moonen writes:
> > I was thinking about the original initiator, not the exchange
> > initiator.
>
> Ok, but this then imposes an awkward new requirement to remember the
> "original original initiator," as it were. Today the initiator of the
> rekey becomes the original initiator of the re
us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen
From: Tero Kivinen
To: Scott C Moonen/Raleigh/i...@ibmus
Cc: ipsec@ietf.org
Date: 09/08/2010 08:19 AM
Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00
Scott C Mo
Scott C Moonen writes:
> > I think it would simplify the implementations and the protocol by just
> > limiting that only responders can be token makers without loosing any
> > of the functionality.
>
> I don't think we should limit this. First, rekeys can easily reverse the
> sense of who is init
edin.com/in/smoonen
From: Tero Kivinen
To: ipsec@ietf.org
Date: 09/08/2010 06:07 AM
Subject: [IPsec] Comments to draft-ietf-ipsecme-failure-detection-00
Sent by:ipsec-boun...@ietf.org
The section 2 describing RFC4306 crash recovery is not complete. It
does not
The section 2 describing RFC4306 crash recovery is not complete. It
does not include the normal processing happining on the peer that is
not rebooting.
I suggest adding following text:
--
When the one peer loses state or reboots i
22 matches
Mail list logo
