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

[Magnus Westerlund <[e-mail]>]

Hi,

I think the proposed solution in these email is fine. I am also fine 
with maintaining the split. But please be clear about it.

Cheers

Magnus

[e-mail] wrote:
> 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
> 




-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

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