netdev - Re: [PATCH] af_key: parse and send SADB_X_EXT_NAT_T

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 22 Jan 2009 12:00:22 +0200
From:	Timo Teräs <timo.teras@....fi>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] af_key: parse and send SADB_X_EXT_NAT_T_OA extension

[Offtopic: looking latest openswan code it does look a lot
better too. It looked quite different when checked it out
some years ago.]

Herbert Xu wrote:
> On Thu, Jan 22, 2009 at 11:24:41AM +0200, Timo Teräs wrote:
>> In DMVPN/GRE case, the NAT-OA from IPsec would not be used
>> unless the NAT-OA is set on neighbour cache. This would not
>> happen unless NHRP can authenticate it. In DMVPN case you need
>> a valid certificate to give the ranom NAT-OA in any case. So
>> if you lie about your NAT-OA I can just revoke you.
> 
> I don't see how NHRP authentication would help if the attacker
> takes over someone else's address and causes packets for the
> third party to go to it.
> 
> As to revoking the attacker's access, that's like saying "I'll
> run an open telnet port but if you try to sniff my psasword I'll
> revoke your access" :)

Sorry, I misunderstood the point in the beginning. Yes, if
someone else has valid cert, and has possession of the same
public IP and knows the private-ip I am using, and makes
SA with that info, he might be able to steal my traffic.

Good point.

And thinking more about it, NAT-OA might be even same for
multiple separate clients (if they are double natted).

>> Or do you have, other recommendations how to distinguish peers
>> behind same public IP than NAT-OA? Maybe we add the certificate
>> subject to xfrm state and neighbour cache. And use that?
> 
> Yes I think that is a much better solution for this.

Still, connecting it with variable amount length of data
(like cert subject) might be cumbersome (extending the
APIs, structs, especially neighbor cache).

Then again it might not be easy to come up with identifying
information if we limit it to 32-bits or 64-bits or so.

Ok, I'll think about this more. Ideas would be appreciated
here.

- Timo

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html