[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: order/nesting of IPsec headers (transport mode)
Aug 22, 97 11:45 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk
Karen, I think any one of the other combinations should be
mandated ONLY if there's a genuine application need for it
out there in the market.
My preference is to let the vendors have the flexibility to
choose what combinations to offer their customers. Forbidding
a combination would be a shame if a customer were to ask for
a specific combination and the vendor were willing to provide it.
I'm assuming interoperability wouldn't be an issue.
- Ly
>
> Folks,
>
> Recent email has raised the question of what order/nesting of IPsec
> headers should be supported in transport mode. In general, we've been
> assuming that ONLY the combinations of IPsec headers listed as 1-3 below
> should occur in transport mode. ("above" = higher in the protocol
> stack, "below" = lower in the protocol stack. So, for example, TCP is
> "above" IP):
>
> 1. AH only
> 2. ESP only
> 3. ESP above AH (i.e., in the outbound direction, do ESP processing,
> then do AH processing)
>
> What is the sense of this community with regard to other combinations,
> e.g.,:
>
> 4. AH above ESP (i.e., authenticate first, then encrypt)
> 5. AH above AH
> 6. ESP above ESP
> 7. AH above AH above ESP
> 8. AH above ESP above AH
> 9. etc.
>
> Should support for any of these be mandated? allowed? forbidden?
>
> Thank you,
> Karen
>
>
References: