RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT traversal, M3, also L2/L19/L24)

["Hancock, Robert" <[e-mail]>]

Hi,

comments on the NAT traversal questions (M3, also L2/L19/L24):

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]] 
> Sent: 01 June 2006 15:23
> To: [e-mail]
> Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-09
> 
> 
> Hi,
> 
> M3. NAT traversal for GIST.
> Section 7.2:
> 
> What plans are there for clearly defining NAT behavior for 
> GIST and the 
> relevant NSLPs? I think one should avoid repeating the 
> mistake with NATs 
> of not specifying the behavior sufficiently for NSIS. Thus I 
> think there 
> is need to specify in great deal what is going to happen at 
> the translation.

There is already an individual I-D which describes the required
behaviour on a NAT, draft-pashalidis-nsis-gimps-nattraversal-02.txt
(see in particular section 6). I believe that this document should
become a working group document (of at least some working group -
I'm not clear on the relationship with behave here). 

What we've tried to do so far is distinguish the GIST specification,
i.e. what nodes implementing GIST have to do, from the NAT
specification, i.e. what NAT nodes have to do with GIST messages.
The overall solution is outlined here in the GIST spec, but there
is a lot more detail that can be added about what NATs should do
(specifically in terms of managing their bindings) which is not
really a concern of the GIST implementor so it seems reasonable
to keep the two separate.


> L2. Section 3.3, page 12, second paragraph:
> "  In addition, it should be noted that NAT traversal almost certainly
>     requires transformation of the MRI field in GIST messages (see
>     Section 7.2).  Although the transformation does not have to be
>     defined as part of the standard, the impact on existing GIST-aware
>     NAT implementations should be considered."
> 
> It seems that not defining the NAT behavior for GIST can potentially 
> cause interop problems and make it very hard to use. What is 
> the plans 
> for addressing this? Are there already existing GIST-aware NATs?

This is probably badly worded. What we are trying to say is that, 
just as there is a split:
a) the GIST spec, and
b) how NATs handle GIST messages

when you define a new MRM there are two things to do:
a') how to modify GIST implementations to handle the MRM
b') how to modify NATs to handle the new MRM

Section 3.3 is saying that the information provided as part of
(a') does not have to define all the details of NAT traversal, 
but that (b') has to be considered, e.g. if necessary as an 
extension to the base GIST nat traversal specification.

(As an aside, there is conceptually a class of MRMs that will in fact be
transparent to NATs. It may be valuable to highlight those in some
way so that they can be deployed without having to update NATs
where the update only consists of the information "you don't have 
to do anything".)

(Another aside: the GIST NAT traversal functionality has been
implemented by at least one team. I don't believe it has made
it into any standard distributions. The 'existing' in the spec
means 'existing at the time that the new MRM is being proposed'.)

> L19. Section 7.2, page 74:
> 
> "Note that Confirm messages are not translated."
> 
> Why isn't them? Also where is that specified? And what is 
> really meant 
> with "not translated"?

Well, the solution is designed so they don't need to be translated. 
(If they did, it would be very tricky, since often they are 
carried in C-mode and are invisible to NATs anyway.) Probably
the specification should say more explicitly "only Query messages 
and messages with a NTO are translated by the NAT".

"Not translated" means "the payload of the UDP message is not
translated". So that can also be made more explicit.

> L24. Section A.3.8:
> "the number of GIST payloads translated by the NAT"
> 
> The NAT? There might be several NATs on the path and it is 
> not clear how 
> that is handled. One concern would be if different NATs translate 
> different fields.

The idea is that the 'list of translated objects' field contains
the objects that have been successfully translated by every NAT.
In other words, it is the intersection of the translation capabilities
of the set of traversed NATs. The first NAT initialises it, subsequent
NATs may have to remove objects which it could not translate.
The "Type-Count" field is just the length of this list (to allow
the message to be parsed). This needs to be made clearer in the spec.

cheers,

robert h.

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis