See my previously sent email. There is still a problem. I can explain more once
I have a real keyboard
Sent from my iPhone
On Jul 2, 2015, at 17:29, Yoav Nir ynir.i...@gmail.com wrote:
On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni ietf-d...@dukhovni.org wrote:
On Thu, Jul 02, 2015 at
Host to host IPsec is very rare.
But that's what we are trying to change :)
But regardless, let’s assume that the local address is 198.51.100.2. So the
quintuple for the connection would be (UDP, 198.51.100.2:704, 192.0.2.5:53)
I don't think you want a tunnel per netflow, and still
The reverse failed. It is only useful in private cloud deployments lacking
other types of authentication for publishing pubkeys (ldap, Kerberos , etc)
Sent from my iPhone
On Jul 2, 2015, at 19:01, Yoav Nir ynir.i...@gmail.com wrote:
On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni
On Fri, 3 Jul 2015, Yoav Nir wrote:
Seems like a limitation of DNS security. DNSSEC can authenticate that “mallory
claimed that mallory.example.com is at 8.8.8.8”, but DNSSEC does nothing to
tell me whether the claim is true. Ordinarily you gain nothing by pointing your
DNS name at a wrong
Hi
I see that our milestones still contain a DANE with IPsec document, although
the WG has not yet discussed or adopted such a document.
There is one proposed document (draft-osterweil-dane-ipsec). That one ties DANE
to opportunistic encryption. While interesting, I think we need a far more
On Thu, 2 Jul 2015, Viktor Dukhovni wrote:
The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP
address and a DANE record. The DANE record can be used to identify the
certificate or raw public key used in IKE.
What prevents IP address hijacking (mallory.example publishes
On Thu, Jul 02, 2015 at 06:40:45PM +0300, Yoav Nir wrote:
What prevents IP address hijacking (mallory.example publishes
alice.example's IP address and now mallory's IPSEC keys are used
to encrypt traffic to alice)?
Not sure I follow. Mallory publishes
- mallory.example.com IN A
On Jul 2, 2015, at 6:03 PM, Viktor Dukhovni ietf-d...@dukhovni.org wrote:
On Thu, Jul 02, 2015 at 05:13:01PM +0300, Yoav Nir wrote:
The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP
address and a DANE record. The DANE record can be used to identify the
certificate
On Jul 2, 2015, at 6:48 PM, Viktor Dukhovni ietf-d...@dukhovni.org wrote:
On Thu, Jul 02, 2015 at 06:40:45PM +0300, Yoav Nir wrote:
What prevents IP address hijacking (mallory.example publishes
alice.example's IP address and now mallory's IPSEC keys are used
to encrypt traffic to alice)?
On Jul 2, 2015, at 8:08 PM, Viktor Dukhovni ietf-d...@dukhovni.org wrote:
On Thu, Jul 02, 2015 at 08:04:37PM +0300, Yoav Nir wrote:
Not sure I follow. Mallory publishes
- mallory.example.com IN A 192.0.2.5
- mallory.example.com IN TLSA
Mallory publishes her own TLSA record for
On Thu, Jul 02, 2015 at 09:02:03PM +0300, Yoav Nir wrote:
Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5
supercedes or displaces Alices.
Ah, I see the source of my confusion.
I never think of a PAD as a table indexed by IP address. The key for
the PAD is a peer, so
On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote:
At the end of the day though, IPSEC needs to apply policy to
application traffic presented to the kernel (almost universally)
via the socket API. The socket API gives the kernel a transport
endpoint UDP/192.0.2.5/53, how is the
On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni ietf-d...@dukhovni.org wrote:
On Thu, Jul 02, 2015 at 11:29:45PM +0300, Yoav Nir wrote:
The hard part is the transport-mode use-case.
If the SPD entries are specific and pre-configured, the same reasoning as
for VPNs applies. Things change
13 matches
Mail list logo
