[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Don't remove TS from IKEv2



By making TS payloads mandatory, we are missing a powerful feature. I guess,
the current discussion is to make TS optional.

Just like 0.0.0.0/0 means tunnel all traffic, we want to something where we
could say tunnel based on some default policy. This can be done by not
sending any TS payload. The side that does not send TS payload says that he
will tunneling packets based on his local default policy. The side that
accepts a SA without TS payload tunnels packets based on his local policy
which was made after coming to a understanding with the other end.

This would make implementing policies such as "authenticate only H.323" and
"encrypt FTP". I don't think we can do this with the selectors we have now.




> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson
> Sent: Thursday, March 21, 2002 7:10 AM
> To: ipsec@lists.tislabs.com
> Subject: Re: Don't remove TS from IKEv2
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> >>>>> "Michael" == Michael Choung Shieh <mshieh@netscreen.com> writes:
>     Michael> TS does detect mis-config for simple scanario.
> However, it falls short on
>     Michael> more complex cases:
>
>     Michael> 1. FTP, DNS, H323.  (btw, can someone show me what
> the correct TS should be
>     Michael> for FTP and H323?  I still don't know how to do it
> correctly even for FTP)
>
>   Yes, IKEv1 does not.
>   We are talking about requirements for the future. Clearly this
> is something
> we need to fix.
>
>     Michael> 2. dynamic routing.
>
>   You mean you want to use TS 0.0.0.0/0 -> 0.0.0.0/0 ?
>
>     Michael> 3. NAT from several pools (or determined by routing)
>
>   ??? what has that got to do with anything. They are either IP
> addresses or not.
>
>     Michael> 4. change inbound local security policy without
> shuting down whole tunnel or
>     Michael> wait for peer's approval.
>
>   Requirement for IKEv2.
>
>     Michael> These are all customer request features.  right now
> I can only put 0 in
>     Michael> proxy_id (and future TS) and screw up my tunnel.
>
>   None of these correspond to a requirement to get rid of TS.
>
>     Michael> It was pointed out the responder can have wider TS
> to do opportunitic sa.
>     Michael> The problem of it is it only works for client-server
> case and fails in
>     Michael> peer-to-peer case.  Even in client-server scenario,
> most likely the server
>
>   Have you really tried it?
>
>   BTW: Please turn off your silly vacation message, it is broken.
>
> ]       ON HUMILITY: to err is human. To moo, bovine.           |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON
> |net architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/
> |device driver[
> ] panic("Just another NetBSD/notebook using, kernel hacking,
> security guy");  [
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Finger me for keys
>
> iQCVAwUBPJn3wYqHRg3pndX9AQHy7wP9HkeFcDVBtdhwNFGEXQ/DfPIUnpZCryha
> 43HJcL2gIZaKlRI/sZVqxVNcmqKb97dVtj/LR9JOx8RJZeueB7Qvr+LRa2cAap+5
> KT+DRmjpa3FhD8wPbiSaJh9IKtSEjzQq/whygwOb18/Wxz2Nqz4RuyJI2Ap1Jff7
> Vvp/mPGevuU=
> =cSji
> -----END PGP SIGNATURE-----