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. First the
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 the initiator and responder
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 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
either
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 from
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,
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 have
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
no hat
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 the
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
Yaron Sheffer writes:
Alternatively it would simplify things immensely if we mandate that SPIs
be random for implementations that support QCD (possibly only on the
gateway side). Can we do it without having to update RFC 4306?
I think it's enough to require this of the token taker.
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 initiator.
In general, the draft is in good shape. But IMO, we have one major
security issue left: the dependence on SPI values which potentially come
from a small space, i.e. may be repeated in normal operation, or may be
coerced into repeating.
Detailed comments:
- 3. I would have preferred the
On Sep 5, 2010, at 11:03 AM, Yaron Sheffer wrote:
In general, the draft is in good shape. But IMO, we have one major
security issue left: the dependence on SPI values which potentially come
from a small space, i.e. may be repeated in normal operation, or may be
coerced into repeating.
14 matches
Mail list logo
