[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed changes to ESP (andf a little AH too)

<mucho snippage>

> For example, the list had a brief discussion of PMTU and DF bit
> conventions, but our analysis has come up with a pretty good rationale for
> what various implementations should do, and when.

I remember this discussion.  I'm looking forward to seeing what you have to
say on this topic.  (IMHO, the only big issue I see on this front is that
transport sessions (i.e. TCP) should be informed to ratchet down their MSS
when/if using IPsec.  This passing of information can be difficult in certain
circumstances.)

> Also, the currently posted architectuire I-D calls for being able to use a
> variety of IP header fields (and TCP/UDP port fields) as selectors for
> defining SAs or nested sets of SAs (I like the term "SA bundle" as
> suggested earlier).  Yet, I have not seen any implementations that support
> these features, so far, even though the I-D has been out for over 6 months.

Previous work has suggested that for outbound packets and their SAs, the
"per-endpoint" abstraction works well.  This same previous work, however,
does not cover tying inbound SAs to an endpoint.  I have some ideas, but I
look forward to learning other approaches to the problem.

<SNIP!>
> So, that's why I'd like to change to make 32 a MUST support, and multiples
> of 32 be recommemded optional window sizes.

My current experience with replay is limited, hence I do not feel qualified
to comment on this just now.  I look at it as something new to learn.  :)

> 	Your question about tranform document vs. transforms deserves a
> thoughtful reply.

It's a tricky question that affects:

	1.) Key management
		* What do I negotiate?
		* What allows better policy definitions?

	2.) AH and ESP code
		* What abstraction to my kernel-loadable modules implement?
		* What allows better policy definitions?

	3.) APIs for both key management and endpoint security
		* What do I offer to the user or key management programs?
		* How do I manually administer such things?

> However, one will still need to negotiate "transforms" as part of SA
> management, and it's up to the Wg to decide how many of these MUST be
> supported, vs. ones that MAY be supported, etc.
<SNIP!>
> One selects the combinations of algorithms and options via SA management,
> and we have chosen to label the bundled combinations "transforms."

Okay.

> I hope this explanation lays to rest any rumors about the demise of AH.  I
> do see a diminished role for AH once we have ESP implementations that
> support encryptionless SAs, but there will still be uses for AH.

There are plenty of uses for AH, even with encryptionless ESP.  These
include (in order of importance):

	1.)  Use of certain IP/IPv6 options w/o having to encapsulate them.
	     Source routing is the foremost example that comes to my mind.
	     These options, while used hop-by-hop, only need to be really
	     authenticated end-to-end.

	2.)  AH has been sucessfully exported.  I'm under the impression
	     that ESP is "encryption-enabling" as per dain-bramaged U.S.
	     export control law.

	3.)  Given the way IPv6 handles its payloads and options in discrete
	     next-header units, AH fits in better (IMHO) with IPv6
	     processing.

Thanks for the reply, and see you in Memphis!

Dan
References: