[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2 traffic selector subsetting.
On 19 Dec 2001, Derek Atkins wrote:
> > For the peer, it's more than just a convenience -- it's a guarantee that
> > errors of various kinds will not send packets into a black hole. The peer
> > has to decide *somehow* which packets go into the tunnel, and having that
> > independently configured on the two ends is asking for trouble.
>
> Why? I send you what I plan to accept; you send me what you plan to
> accept. Nothing says that these two statements of acceptance have to
> agree, and nothing states that you have to actually comply.
Except that if they don't, or you don't, then the connection *doesn't work*
and it's very hard to figure out why. IPsec is already far too prone to
this sort of mysterious problem.
What you say is correct, but is relevant only in a perfect world. In the
real world, protocols which *check* that the two ends are in agreement on
the details are far more practical, robust, and usable.
There is also a definite possibility, as in our Opportunistic Encryption
proposal (draft-richardson-ipsec-opportunistic-03.txt), that one end
doesn't even *know* what packets the other end wants until the other end
proposes the connection.
Yes, these problems can be solved by using hypothetical policy protocols
to negotiate all of this, but (a) that adds unnecessary complications, and
(b) proposals for practical protocols should not invoke the Tooth Fairy to
solve all the hard problems.
> Basically, you're saying that I need to send you the equivalent of all
> the firewall rules that affect you?
You should tell me what packets you will accept, and what packets you
propose to send, so that I can check that against my understanding of what
the connection is supposed to be, and verify that the connection can be
established *successfully*.
Henry Spencer
henry@spsystems.net
References: