[SIPForum-techwg] Discussion on why 7.2.5 (authentication etc. for static mode) differs from 7.1.6 (for registration mode)

Theo Zourzouvillys theo at crazygreek.co.uk
Tue Feb 17 19:19:41 EST 2009


On Tue, Feb 17, 2009 at 11:46 PM, Cullen Jennings <fluffy at cisco.com> wrote:
> This sounds good in theory but let's talk about practice. Let's say the SP
> proxy is running on a Unix box and the VPN terminated on some VPN
> terminator.  How would the proxy know which VPN it came in over?

in practice:

for simple non RFC1918 addressed customers, you can use VPN3000s with
L2L connections with src/dst filters on.  The concentrators are
plugged into a vlan on edge proxies which are configured to slap the
right authentication info into the message when coming from that
specific vlan with the customers source address.

of course we have some customers that insist on using RFC1918
addresses - for these, you could terminate on 7600s and build customer
specific vlans right up to the edge proxies which have trunks to the
(linux) boxes, then we use linux network namespaces for VRF-lite style
functionality in the proxies.  Even without network name spaces you
could easily use nfmark or such.

i'm sure that other VPN vendors have a similar way of doing things, it
just so happens all our VPN and L2+3 stuff is Cisco :)

> Consider
> another case, the VPN terminates on the unix box running the proxy. What OS
> calls would the proxy use to find out which VPN the message came in over or
> if it even came in over a VPN? It's not easy.

in linux, you can use IP_PKTINFO ancillary messages then access the
ipi_ifindex (see man (7) ip) - any OS that doesn't provide something
like this would be a pretty poor choice for implementing a network
oriented stack on :-)

> This problem existed then and was, to my knowledge, never resolved.

don't get me wrong, i'm _all_ up for TLS instead of IPSec - but the
above can (and does) work in practice

 ~ Theo


More information about the techwg mailing list