[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Bundle Proposals
At 09:17 06/11/98 -0500, Tim wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Note subject change. Further, we seem to be diverging past the original
*intent* of the discussion. I'll clarify what I thought I was talking about.
I want clarification of the implementation when there is
1) a single SA payload
2) in a single quick mode negotiation
3) between 2 peers only
4) there are multiple proposals, and
5) the proposals have the same proposal number.
There are 2 issues (and they are sort of separate).
1) What is the order of application of the negotiated services (ESP, AH,
IPCOMP)?
2) What encapsulation mode is specified and used for each of those services.
Options, Order Issue
1) The services are applied in the order proposed, in the outbound
direction. For example, if ESP+IPCOMP+AH is proposed, the packet looks like
(ignore encapsulation for now, please)
| AH | IPCOMP | ESP | packet |
2) The services are applied in the order proposed, in the inbound
direction. Same example:
| ESP | IPCOMP | AH | packet |
3) The services are applied on reasonable rules of application, regardless
of the order of proposal. Same example:
| AH | ESP | IPCOMP | packet |
Discussion, Order Issue
If option 1 or 2 is chosen, then the responder must not change the order of
the proposals. While this allows more flexibility, most of that additional
flexibility probably has debatable value. (Remember, we're talking about a
single connection between two peers, not layered SAs between different peers.)
Proposal 3 may ease implementation issues.
Options, Encapsulation Issue
1) Each service specifies its encapsulation mode. This means that the
services are not conceptually treated as a single SA.
2) The services are conceptually treated as a single SA, and they all
specify tunnel encapsulation for an tunnel mode SA, and they all specify
transport encapsulation for a transport mode SA.
3) The services are conceptually treated as a single SA, and the they are
all specify transport encapsulation for a transport mode SA, but the
inner-most service specifies tunnel mode encapsulation and all other
services specify transport mode encapsulation for a tunnel mode SA.
Discussion, Encapsulation Issue
I don't see any reason to support option 1. First, it's not compatible with
option 3 for the order issue. Second, the use of any additional IP headers
between the services' headers appears to be a waste of bandwidth without
providing any additional services.
Option 3 might ease implementation issues, since that's the effect of
iterating SAs, but it's not compatible with option 2 of the order issue
either.
Votes
My votes are for option 3 of the order issue (even though we've already
implemented option 1) and option 2 of the encapsulation issue.
Note that this particular choice does not preclude the negotiation of
different SAs between the same peers to get the effect of multiple separate
SAs.
More below as well...
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com
<http://www.timestep.com>http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
<<<<<<<<<<<<<<<<<<<<<<<<
The order issue should not be option 3). It makes future extensions (new
transformations)
impossible. If somebody comes up with a transformation that can be used in
several
places (unlike the ones we have), we have a serious problem.
It should be 1) or 2). ESP+IPCOMP+AH is an illegal combination, then.
For the encapsulation issue, I'd vote for 1). Same reasoning.
Jörn Sierwald
References: