Yaron: The security considerations are focused on details of the QCD solution,
rather then on the threats we are dealing with. These threats are non-trivial
to describe, since an active MITM attacker can easily cause an IKE SA to be
reset. OTOH, we don't want an active non-MITM attacker to be ab
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
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
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
>>
>>
>>
>>
>>
[IPsec] Issue #194 - Security Considerations should discuss
the threat
Sent by:ipsec-boun...@ietf.org
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 i
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
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
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
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'
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
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 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
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
13 matches
Mail list logo
