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

[<[e-mail]>]

Hi all,

>> 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). 

I think that the NAT traversal material should belong in a separate
document - as we have seen with STUN, for example, the NAT
considerations
change - so I think it makes sense to have it separate.

>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.

Agreed.

>> 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.

I think a rewording of the text in 3.3 would be a good idea.

>(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.

Please do make it 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.

If you can add this to your ToDo list for the update, that would be
great.

thanks,
John

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