Re: [MEXT] AD review of mext-nemo-v4traversal

On 23/08/08 12:23 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote:

> I have reviewed this specification. I did not find any showstoppers, but
> there were a number of issues that need to be addressed. I am expecting
> a revised draft and some discussion about question marks below.
> 
> Please find my detailed comments below. First the technical ones:
> 
>> Scenario 3: Home Agent behind a NAT
> I think you are making your life unnecessarily hard. Is there a true
> demand for this?

=> Not in my opinion, but we discussed this for a long time on the list and
some people thought it was needed. This paragraph you quote doesn't do
anything though, it simply mentions the scenario and says that the spec
assumes a public IPv4 address. The offending text is below.
> 
>> 2)
>> configure one public address and make the home agents share the
>> public address.
> 
> How would this work if the NAT happens to forward one BU to one home
> agent and the next BU the a second one?
> 
> Please explain better or remove.

=> This is not right of course, not sure how it slipped into the text.

> 
>> Another possible solution is to designate one home agent
>> on the home link for IPv4 traversal.  The NAT device should associate
>> that home agent with the public IPv4 address configured on it for v4
>> traversal.  In all cases above, both the 'AAAA' and 'A' records
>> returned for a particular name MUST correspond to the same physical
>> home agent
> The first and third sentences seem to be in conflict. If one HA is used
> for IPv4, then presumably the other ones are used for IPv6. If so, when
> a mobile node moves from IPv6 care-of address to an IPv4 care-of
> address, it has to switch the home agent.

=> Correct. Although that scenario is not seen as important, I would prefer
to remove those three sentences from the spec.

> 
>>    When a mobile node acquires both IPv4 and IPv6 care-of addresses ws at
>>    the foreign network, it SHOULD prioritize the IPv6 care-of address
>>    for MIP6 its binding registration.  The mobile node MUST NOT register
>>    both IPv4 and IPv6 care-of addresses to its home agent.
> 
> This is the priority, but its also likely to have the same problems as
> we have with dual stack hosts getting long timeouts due to trying out
> broken IPv6 connectivity. Look at the Stuart Cheshire's technical
> plenary presentation, for instance.

=> Oh, I'm aware of the problems with IPv6 connectivity *today*. However, I
really don't think we should design the spec around what can be seen as a
transient problem. I mean, how many people outside IETF know about those
problems? The decision about CoA selection has profound implications that
will stay in the spec for a long time.
IPv6's connectivity issues are, IMO, clearly tied to the fact that it's not
used today. Once it's used enough for this spec to be deployed, I doubt very
much we will be discussing how slow it is compared to IPv4. So, I'm
reluctant to add further complication to CoA selection based on this issue.

The recommendation to use IPv6 first follows RFc 2893 (now 4213).

I would suggest that you have an
> explicit specification of the recovery mechanism: trying out both in
> parallel, trying one first and then falling back -- I do not have the
> details but you have to have a recovery mechanism.

=> You mean ICE? :) seriously, how complicated do you want it to be?
We could do a "try v6 and if BU is rejected/timed out three times then try
v4" is that ok? 

> 
> Similarly, it would be very useful if the document contained better
> instruction about when a mobile node sets the F flag. If there is no NAT
> but a firewall, the mobile node may wish to use UDP encapsulation. Would
> it be possible to have the mobile node revert back UDP encapsulation if
> the direct encapsulation does not appear to be working?

=> Sure, section 5.1 says:
  The mobile node can request to always use
   UDP encapsulation by setting the F flag in the binding update.  If
   the home agent does not agree to the request, it MUST reject the
   binding update with the new Status code:

      144 Cannot force UDP encapsulation

   Alternatively, the home agent can force UDP encapsulation by setting
   the F flag in the NAT detection option included in the binding
   acknowledgement.

> 
>> Refresh Time
>> 
>> A suggested time (in seconds) for the mobile node to refresh the
>> NAT binding.  If set to zero, it is ignored.  If this field is set
>> to all 1s it means that keepalives are not needed, i.e., no NAT
>> was detected.
>>   
> How would a home agent know what behaviour to expect from a NAT in a
> visited network (e.g., user's home DSL box)?

=> It doesn't, and that's why the default is the least common denominator.

> 
> Please provide additional discussion on how to set this field, what the
> manageability considerations are, etc.

=> There is no clever solution for this, but what we can say is if the HA
doesn't know better, it should use the default value in the spec. Is this ok
with you?

>> The Type field MUST NOT be
>> assigned the values 4 or 6 to make sure that the receiver can tell
>> the difference between the Type field and the IP version field in a
>> packet that contains an IP header after UDP.
> 
> See RFC 4928 and 
> http://www.iana.org/assignments/version-numbers/version-numbers.xhtml
> 
> In short, other protocols have done in the past, and restricted
> themselves to values 0 and 1, in order to allow for the (admittedly
> unlikely) allocation of a new IP version number.
> 
> Please consider the same approach here.

=> Sure, we only use 1 anyway.

> 
> (And why do we have to distinguish between the TLV and IP -- I thought
> you negotiated the use of TLV?)

=> The BU is sent in IP only, so you need to tell the difference between a
BU and a traffic packet.

> 
>> However, UDP MUST NOT be used to encapsulate
>> the binding update message when the mobile node is located in an
>> IPv6-enabled network.
> 
> MUST NOT is quite strong here. I do not think the reasons for using MUST
> apply here. And indeed, there might be future needs to employ UDP over
> IPv6 as well, if there was a (bad) firewall that only support UDP and
> TCP passthrough.

=> But there are many scenarios where we can do things to cheat a firewall,
is this really a good idea? What if the FW only allows port 80? If the
firewall is "bad" in our eyes, may be there is a reason for that in someone
else's eyes.
One of the reasons for the MUST NOT was to simplify the security scenarios
by eliminating the two scenarios of IPv6/UDP/IPvx. But I agree that it might
not, strictly speaking, comply to the definition of a MUST.

> 
>> The IANA should allocate and permanently register new TLV-header
>> types and Status field values from IETF RFC publication.  This is
>> for all RFC types including standards track, informational, and
>> experimental status that originate from the IETF and have been
>> approved by the IESG for publication.
>>   
> 
> Please use RFC 5226 terminology instead. I think you mean: New
> TLV-header types and Status field values are allocated via IETF Review
> [RFC5226].

=> Ok.

> 
> Missing things:
> 
> - Is it really the case that this document does not need to reference
> RFC 4877, even if both talk about the encapsulation formats?
> 
> - What about IKEv2, RFC 4306?

=> Ok 

> 
> - There is no discussion of the interaction between NAT detection &
> traversal in IPsec vs. in DSMIP.

=> Could you elaborate? What needs to be discussed?

> 
> - There is no discussion about procedures for IPv4 addresses "returning
> home". You could rule that not supported, but even in that case it
> should at least be mentioned.

=> ok.

> 
> Editorial:
> 
>> In this specification, extensions are defined for the binding update
>> and binding acknowledgement.  It should be noted that all these
>> extensions apply to cases where the mobile node communicates with a
>> Mobility Anchor Point (MAP) as defined in [RFC4140
>> <http://tools.ietf.org/html/rfc4140>].  The
>> requirements on the MAP are identical to those stated for the home
>> agent, although it is unlikely that NAT traversal would be needed
>> with a MAP as it is expected to be in the same address domain.
>>   
> First, 4140 should be 4140bis.

=> ok.

  But I am curious that you mention HMIP
> and not any of the other things that might apply equally well, such as PMIP.

=> Well, this line was written before PMIP, but anyway PMIP has its own
accompanying spec for DSMIP, which refers to this spec. Of course a number
of things in this spec don't apply to PMIP so it's best to not confuse
people. Also, while on the topic, FMIP use with DSMIP would be a bad idea of
course unless one writes a separate spec detailing how they could be used in
very specific scenarios.

> 
>> NAT box
> s/NAT box/NAT/
> 
>>  The security implications of this
>>    mechanism are discussed in the security considerations section.
>>   
> This appears in Section 3.3.1. This does not seem like a very useful
> statement. Everything in this document is hopefully discussed in the
> security considerations section!
> 
> Consider removing the statement.
> 
>> When a mobile node acquires both IPv4 and IPv6 care-of addresses at
>> the foreign network, it SHOULD prioritize the IPv6 care-of address
>> for MIP6 its binding registration.
> ... for its MIP6 binding ... ?

=> ok.

> 
>> If no NAT
>> is detected between the mobile node and the home agent, the mobile
>> node assumes that it is in a foreign network that supports IPv4
>> public addresses.  Otherwise, the mobile node assumes that private
>> addresses are used in the foreign network.  Note that this assumption
>> is only valid for the purposes of the signaling presented in this
>> specification.  A mobile node SHOULD NOT assume that its IPv4 address
>> is globally unique if a NAT device was not detected.
> 
> This was very hard to parse. What is "supports IPv4 public addresses"?
> How is that different from "MN's IPv4 is globally unique"? Isn't the
> only thing that you need to know here: can the mobile node be reached
> from the home agent by sending an IPv4 packet to its address?

=> yes.

> 
>> 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses)
> 
> I was surprised that this section says nothing about keeping the port
> numbers in the binding cache entry. Section 5.2 talks about this, but
> that is much later.

=> The scenarios sections are supposed to just list the scenarios, if
anything I think we should remove the solutions from those sections.

> 
>> Additionally, this option can include an IPv4 home address in the
>> case of Dynamic IPv4 home address configuration (i.e., if the
>> unspecified IPv4 address was included in the binding update).
> Can? It always will, right? s/can include/includes/ Or are you
> considering some error case. Please be more specific here.

=> ok.

> 
>> To
>> avoid confusion in the correspondent node, the mobile node SHOULD
>> deregister its binding with each correspondent node by sending a
>> deregistration binding update.
> This text (and surrounding paragraph) in Section 6.1 feels like it is in
> the wrong place. This has nothing to do with IPsec and IKE, its part of
> the basic behaviour of the mobile node.

=> ok

> 
>> .. requires
>> an option type.  This option is included in the Mobility header
>> described in [RFC3775].
> This was hard to read. Maybe: ... requires a new option type allocation
> for a mobility option [RFC 3775].

=> ok.

> 
> Jari
> 

_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext