Yoav Nir <y...@checkpoint.com> wrote:
>> I also read: draft-mao-ipsecme-ad-vpn-protocol and while conceptually
>> I found it okay, I think that the protocol should be inside IKE.
> Funny, I came to the opposite conclusion. I think it's too much like
> IKE.
> But actually, this should be split in two.
> ADC to ADC communications, like the REDIRECT and SESSION could easily
> run over an Informational exchange in IKE.
I agree.
> But the ADC to ADS communications are, to quote section 1.1, "a client
> and server protocol". And there is no reason to assume that the ADS can
> even do IKE - it's a controller. So I think those parts of the protocol
> could be done in a web service.
I think that the right model to think about here is EAP, IKE, Radius.
I think that the much of the ADC<->ADS protocol is EAP-like in nature.
I think that it should be carried in IKE, much like EAP is, to a hub.
The Hubs (which are small in number, and are well managed) would speak carry
ADVPN in PROTOCOL X, to the ADS.
Protocol X may well be TCP over IPsec, or just TCP, or maybe it's RESTful
HTTP(s).
I don't think it matters a hoot if the ADS can do IPsec. It's IKE.
IKE is a UDP based protocol, and if you remove the IPsec requirement, it's
just another deamon.
It is the *HUB* and the *SPOKES* where I think one wants to remove as many
moving parts as possible, and in particular, remove any additional
firewall/policy complexity.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
pgpVWfCcMCDZL.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
