[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on VPN framework document
(comments on
ftp://ftp.ietf.org/internet-drafts/draft-gleeson-vpn-framework-00.txt )
Hi Bryan,
just read-through your draft on VPN frameworks and I have a few comments:
1) L2TP seemed to get the thumbs-up on all count except security. If IPSEC
is applied to the resulting
L2TP UDP/IP packet in TRANSPORT mode, that does seem to solve the problems.
I have never seen IPSEC-tunnel as being useful for LAN to LAN. It is fine
for host-to-host, and for host to security gateway, but not LAN-LAN. Maybe
it can be fixed, but in the meantime:
L2TP tunnel packets protected with ESP encryption would add as little as 9
bytes of ESP overhead.
The encryption algorithm used may add another 8 to 14bytes and the
authentication option another
12 bytes. However, these encryption/authentication overheads would be
incurred whatever route you take, so it comes back to 9 bytes per packet
additional for ESP overhead. Four bytes of this overhead is used to
prevent replay attacks, and four bytes are used to multiplex. The four
bytes of replay protection are a general requirement, so they remain 5 bytes
(multiplexing and next-hdr bytes) are the only true over head of applying
ESP transport mode.
2) VPRNs look very complicated. The document is VERY VPRN-heavy, I feel. I
am concerned that the VPRN model is both restrictive, inflexible and relies
on security being managed for you by the VPRN provider. I much prefer the
VLL approach described - just so you know :)
3) I am not convinced the 'Compulsory' tunneling for remote access will be
attractive (I'll get some heat for that one no doubt). Again, it is
inflexible, insecure on the outer PPP links, and relies on the ISP providing
authentication services. To protect the LAC-LNS flow would mean sharing
ipsec security information with the ISP. Besides, 'Voluntary' sounds more
friendly :). I think a vanila IPSEC tunnel in valuntary mode would do most
folk - no L2TP.
Steve.
Follow-Ups: