Frederic Detienne writes:
> In order to secure QCD, the token has to include all the fields that
> can be used for routing a packet to any given server:
>
> - source/destinatition IP
> - protocol (UDP / ESP)
> - source/destination ports if applicable
But the problem is that the IPsec implemen
On 21 Oct 2010, at 12:33, Yoav Nir wrote:
>
> On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote:
>
>
>
>> The section 10.4 seems to assume that attacker cannot force the load
>> balancer to send the faked packet to any other cluster member than the
>> one mapped by the source IP-address of the
Hi Yoav,
as I mentioned in my mail yesterday, #194 is not just about this
particular issue.
Thanks,
Yaron
On 10/21/2010 12:33 PM, Yoav Nir wrote:
On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote:
The section 10.4 seems to assume that attacker cannot force the load
balancer to se
On Oct 21, 2010, at 11:59 AM, Tero Kivinen wrote:
> The section 10.4 seems to assume that attacker cannot force the load
> balancer to send the faked packet to any other cluster member than the
> one mapped by the source IP-address of the packet. As the algorithm
> how the load balancer really
David Wierbowski writes:
> Thanks for your answers, but I should have been more specific in my
> question. I was not asking how a MITM could break IKE. I was asking for
> an example of how draft-ietf-ipsecme-failure-detection-01 increases the
> risk over what we have today in IKE. That's what I'
bigger issues.
Dave Wierbowski
From: Yoav Nir
To: IPsecme WG
Date: 10/20/2010 04:10 AM
Subject:Re: [IPsec] Issue #194 - Security Considerations should
discuss
the threat
Sent by:ipsec-boun...@ietf.org
One week, and no replies...
I will leave
heffer
To: Yoav Nir
Cc: David Wierbowski/Endicott/i...@ibmus, IPsecme WG
Date: 10/20/2010 10:21 AM
Subject: Re: [IPsec] Issue #194 - Security Considerations should discuss
the threat
In fact I was referring to the whole extension. OK, since you&#x
could only do so if he hi-jacked the original IKE_SA negotiation and is
now impersonating the remote security endpoint. In that case you have
bigger issues.
Dave Wierbowski
From: Yoav Nir
To: IPsecme WG
Date: 10/20/2010 04:10 AM
Subject: Re: [IPsec] Issue #194 - Security Cons
? I would think he
could only do so if he hi-jacked the original IKE_SA negotiation and is
now impersonating the remote security endpoint. In that case you have
bigger issues.
Dave Wierbowski
From: Yoav Nir
To: IPsecme WG
Date: 10/20/2010 04:10 AM
Subject:Re:
reset? I would think he
>> could only do so if he hi-jacked the original IKE_SA negotiation and is
>> now impersonating the remote security endpoint. In that case you have
>> bigger issues.
>>
>> Dave Wierbowski
>>
>>
>>
>>
>>
ave
bigger issues.
Dave Wierbowski
From: Yoav Nir
To: IPsecme WG
Date: 10/20/2010 04:10 AM
Subject:Re: [IPsec] Issue #194 - Security Considerations should discuss
the threat
Sent by:ipsec-boun...@ietf.org
One week, and no replies...
I will leave
One week, and no replies...
I will leave this issue open unless I get some suggested security
considerations text.
The first paragraph in section 10.1 says the following. What else is missing?
Tokens MUST be hard to guess. This is critical, because if an
attacker can guess the token asso
12 matches
Mail list logo
