[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
order/nesting of IPsec headers (transport mode)
1. Due to the use of tunneling technologies such as GRE I can imagine a
legitimate case like this:
AH...AH...ESP
This would be caused by GRE packets travelling from one PPTP device to
another inside a network that requires AH on all nodes. It's transport
mode because it uses GRE. The whole packet would be
IPv4...AH...AH...AH...ESP...GRE...
2. I thought the IPv6 folks had text in their specs that said any valid
'next protocol' value was allowed.
3. I recall 1825 said any combination was valid. Was there a list
discussion on why this should have changed? Clearly a fixed set of any
size is simpler than an unlimited set, but what were the reasons for
changing the document?
>Date: Fri, 22 Aug 97 23:45:39 EDT
>From: Karen Seo <kseo@bbn.com>
>To: ipsec@tis.com
>Subject: order/nesting of IPsec headers (transport mode)
>Sender: owner-ipsec@ex.tis.com
>
>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
>
>
>
>