[anonsec] nat traversal scoping

mcr at sandelman.ca (Michael Richardson) Wed, 25 July 2007 21:55 UTC

From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 25 Jul 2007 16:55:25 -0500
Subject: [anonsec] nat traversal scoping
In-Reply-To: <F222151D3323874393F83102D614E0550A4D23BD@CORPUSMX20A.corp.emc.com>
References: <F222151D3323874393F83102D614E0550A4D23BD@CORPUSMX20A.corp.emc.com>
Message-ID: <f88gse$3e8$1@sea.gmane.org>

Black_David at emc.com wrote:
> Taking the areas in reverse order, the current sections 6.1 and
> 6.2 of the draft essentially say that NAT, mobility and multihoming
> issues are out of scope.  Whether they are out of scope is a longer

I am going to deal with each one seperately. This email is about NAT.

Q: If you remove the statement that they are out of scope, does this force
    us to deal with these issues now?

I would prefer not to deal with the issue of NAT-traversal until after
we have some running, interoperable code that does connection-latching.

I think that that connection-latching + transport mode solves some NAT 
traversal issues. The remaining concerns are that we have to be very clear 
about what kind of phase 1 IDs that we use --- on that we can get rough 
consensus after we have running code.

As far as I understand process, deciding to make NAT in scope and the deal 
with it in later documents requires adding milestone items to our charter.
I believe that it is therefore the same as excluding NAT from scope and then 
rechartering later on?