Subject: [mobile-ip] Feedback on NAT draft

From: "Madhavi W. Chandra" <[email-masked]>
Date: Fri, 10 May 2002 10:28:25 -0400

Hi Henrik and Sami,

We've gone through your NAT draft with much interest 
and have a few comments:

1) Is the F bit in the UDP Reg Request Extension needed?  
Probably can let HA make the decision of IP-in-UDP tunneling.
If HA determines that the RRQ did not traverse a NAT box,
it still MAY accept the IP-in-UDP tunneling request based
on administrative policy on the HA.  Don't see the need 
for the MN to mandate this with the 'F' bit, since the HA
is in the better position to decide.

2) Sect. 1.2.  Comparison of IP SRC address against (a) CoA,
(b) Home address, or (c) 0.0.0.0.  Is this only the case
when MN is sending RRQ in Co-CoA case?
Should be made precise, as this does not hold in FA case.

3) For FA case, HA detection of NAT traversal is suspect since
CoA and source IP address (FA egress interface) need not be the same.

We suggest:

Can either append UDP Reg Request Ext with *IP address
of FA* when FA relays the RRQ to HA.  Then HA can compare the IP
SRC against the IP address of FA in UDP ext.  If mismatch, HA
can determine that RRQ traversed a NAT box.

Or, can mandate that the IP SRC used at FA (FA egress interface) 
is the same as the FA CoA.

4) The draft does not specifically state what the tunnel end
point should be...it only states it precisely for the case that the
'R' bit and 'F' bit are set in the UDP request extension in Section 4.6.  
Moreover, it is not clear when the tunnel endpoint is decided...upon 
receipt of the initial RRQ or keepalive?  Please clarify and add 
appropriate/precise text to the draft.

5)  The draft says that periodic keepalive signaling SHOULD be in the
form of an RRQ...this seems like heavy signaling to do every K
seconds.  I'm trying to dig through the nat-vpn archives to find the
thread you mentioned previously.  No luck so far.  Do you have a
writeup of your analysis that I may refer to?  Perhaps the SHOULD should
be relaxed.

Thanks for your consideration.

Regards,
Madhavi

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Sat, 11 May 2002 11:27:06 +0200

Hello Madhavi,

> is in the better position to decide.

The function of the F bit is to have a mechanism to Force
UDP tunnelling to be used also when no NAT is detected.
It seems some people find this desireable, and I agree,
and it also turns out to have a function when handling
the FA R-bit case.

> Should be made precise, as this does not hold in FA case.

Right. It should say e.g. "mobile node IP source address..."

> CoA and source IP address (FA egress interface) need not be the same.

Right, good point.

> is the same as the FA CoA.

Right. The second solution is simpler, and I'd go for that unless
others on the list feel otherwise.

> appropriate/precise text to the draft.

I gather you're not referring to the tunnel end points, really, as those
are at the HA and FA/MN, exactly as for IP-IP tunnelling, but rather
the apparent destination address the HA needs to use for the tunnel.
Yes, we'll add a clarification of this. There's a typo in the relevant
section in draft -02 which may have helped make this obscure, too :-)

> writeup of your analysis that I may refer to?  Perhaps the SHOULD should

Ok, the bandwidth calculation. Let us assume:
	a low-bandwidth channel of 14400 bits per second,
	a keepalive every 20 seconds
	a registration request which is typically some 80 bytes, 
	  IP header included
	a registration reply of the same length
	a binding lifetime of 120 seconds

In this case, the bandwidth consumed by using registration requests
and replies are roughly 5*2*8*80 out of 14400*120, or 6400/1728000,
or about 0.37 % of the channel.

If we compare this with zero-data icmp echo requests/replies, we get
5*2*8*28/(14400*120), or 0.13% of the channel.

Yes, this is less. But no, I can't see about 0.4 % of a 14400 bit/s
channel as heavy signalling.

So here we differ in opinion. I on my part hold that 

	1) registration request keepalives are not particularly heavy, and 

	2) there are benefits to using reg. requests as keepalives,
	   which makes at least a SHOULD appropriate, while 

	3) for extremely! processor-challenged mobiles, it may be heavy
	work to calculate the HMAC-MD5, so we need to use a SHOULD
	rather than a MUST (I think this third point is weak)  
	and finally 

	4) in the FA R-bit case, we *cannot* use reg.  requests /
	replies as keepalives, so we must have an alternative.

	Best regards,

		Henrik

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Mon, 13 May 2002 13:47:45 -0400

> and it also turns out to have a function when handling

We certainly agree that UDP tunneling may be useful even when no NAT
is detected.  I guess the difference is that we feel it can be done on
the HA side...in fact, the HA is the one that should make this
decision.  Not sure why an MN should mandate to an HA what it should
do.  For example, maybe there is an adminstrative firewall policy on
the HA that would require UDP tunneling irrespective of NAT presence.  
In this case, the HA would set up the UDP tunnel.

Can you please elaborate on why you feel the MN is in a better
position to force UDP tunneling on the HA?  Also, what function are
you refering to in the FA R-bit case?

> others on the list feel otherwise.

I agree that this is the simpler and cleaner solution.
 
> section in draft -02 which may have helped make this obscure, too :-)

Right...even though the tunnel is at the HA and 'FA/MN' (actually, on
the NAT box)...it is being determined by the IP SRC of the RRQ, and
not the CoA field.  This should be clearly stated.

> 	replies as keepalives, so we must have an alternative.

Sorry for not being clear.  We were refering to 'heavy signaling'
from the HA's perspective.  If an HA is supporting a large number of
MNs, and every MN is re-registering every 20 seconds, this can easily
overload the HA.  Every incoming registration will require processing
on the HA.

Regards,
Madhavi

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Mon, 13 May 2002 20:37:58 +0200

Hi Madhavi,

Madhavi wrote:
>   Hi Henrik,

This is not an either - or thing. If the MN indicates that it is
able to do UDP tunnelling, then sure, you could do as you suggest,
let the HA indicate tunnelling for policy reasons also in the absence
of a NAT. Having the 'F' bit simply permits the MN to act similarly.
Do you have any particular reason why you don't want the MN to be
able to request this? 

The FA R-bit case, where the 'F' bit is needed, is the one described 
in Section 4.10 of the -02 draft.

> I agree that this is the simpler and cleaner solution.

Ok, good.
> not the CoA field.  This should be clearly stated.

Yes, as I said, we'll add a clarification on this.

> overload the HA.  Every incoming registration will require processing

Ok, I see what you are concerned about. But in view of the hijacking
and DoS scenarios which Francis Dupont brought up recently, I think
it is still very prudent to have a short time between registrations.
If you still want to, you can always use the alternative icmp echo keepalives, 
but I don't think that would be the wise thing to do. We have drafted
a new security considerations section to discuss this in more depth,
too.

	Regards,
		Henrik

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Mon, 13 May 2002 15:40:45 -0400

Hi Henrik,

> Do you have any particular reason why you don't want the MN to be

The MN is indicating that it can do UDP tunneling with the
presence of the UDP Tunnel Request Extension.  The HA can decide
whether to do UDP tunneling irrespective of NAT.  There doesn't seem
to be a role for the MN to force UDP tunneling...unless we are missing
something.  Hence, implementation can be simplified without 'F' bit.

> in Section 4.10 of the -02 draft.

Actually, taken from Section 4.4:

"If a mobile node is registering through a foreign agent but using a
   co-located care-of address, and the agent advertisement from the
   foreign agent had the 'U' bit set, the mobile node SHOULD set both
   the 'R' flag and the 'F' flag in its UDP Tunnel Request Extension, in
   order to make the HA use MIP UDP tunnelling."

I'm not sure I understand...if the RRQ went through a NAT box, the HA
would still be able to detect this and set up the UDP tunnel.  
If it didn't go through a NAT box, why does MN want to force UDP
tunneling just because it is FA 'R' bit case?  Perhaps I am missing your
point.  Maybe if you parsed the following sentence for me (taken from
Section 4.6), it would help:

If the 'R' flag is set but the 'F' flag
   is not set, the home agent MUST NOT assent to UDP tunnelling, even if
   there is an address mismatch.

I'm not seeing the needed 'F' bit functionality in the FA 'R' bit
case.

> it is still very prudent to have a short time between registrations.

But, wouldn't a man-in-the-middle still be able to do a DoS attack by
intercepting each of the re-registrations?  It can still blackhole the
MNs traffic, can't it?

I think the requirement of RRQ keepalives should be relaxed from a
SHOULD, since it is processing intensive on the HA.

> a new security considerations section to discuss this in more depth,

I look forward to seeing the new section.

Regards,
Madhavi

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Mon, 13 May 2002 22:15:23 +0200

Madhavi,

> something.  Hence, implementation can be simplified without 'F' bit.

Correction: You do not find it useful. Other people have indicatet that
it would be useful, so I'd tend to keep it in for that reason. But there
is still the FA R-bit case, too.

> I'm not seeing the needed 'F' bit functionality in the FA 'R' bit

Madhavi, I think it would clear up your questions if you were to read 
section 4.10, which I referred to earlier. It really does answer the
questions you ask here. But in short: In this case, the HA cannot
detect the presence of a NAT in the usual manner, so it needs to be
forced by the mobile node.

...<snip>...
> SHOULD, since it is processing intensive on the HA.

Well, we obviously disagree on this, then. I believe that it is clearly
desireable to keep this as a SHOULD, both for security reasons, and for
the performance reasons discussed in sections 5.1 and 5.2 of the draft.

	Regards,
		Henrik

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Tue, 14 May 2002 10:26:08 -0400

Henrik,

> it would be useful, so I'd tend to keep it in for that reason. But there

Yes, I do not find it useful.  Otherwise, I would not have brought it up.
Perhaps if you share the reasons and be a little more specific, I can find it 
useful too.  Understand that I'm not adverse to it, but at 
present I don't see the need.  And hence, it seems like unnecessary
implementation. 

> forced by the mobile node.

Just because I still have doubts is not a valid reason for you to assume
that I didn't read section 4.10.  As I indicated earlier, we have much
interest in your draft and read it quite carefully.

I understand that the HA cannot detect the presence of the NAT in the usual
way with the FA 'R' bit case...which is why you have carefully explained the
use of the 'U' bit and proper inclusion of the UDP Tunnel Request Extension.

But, how does the 'F' bit help here?  The fact that the UDP Tunnel Request
Extension is present, with the 'R' bit set indicates to the HA that the
FA knows it is behind a NAT (since it advertised the 'U' bit...which is
why the MN included the UDP Tunnel Request Extension).  The HA will notice
the difference in IP SRC, and set up the UDP tunnel.  Did I misunderstand
the behavior?

Thanks,
Madhavi

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 14 May 2002 17:39:46 +0200

Madhavi,

You wrote:
...<snip>...
> present I don't see the need.  And hence, it seems like unnecessary

Please see Sami's reply earlier today on this one. 

> interest in your draft and read it quite carefully.

Fair enough; sorry. I mistakenly got that impression when you only quoted 4.4.

> the difference in IP SRC, and set up the UDP tunnel.  Did I misunderstand

Madhavi, you are right! and I apoligize. The requirements that the MN should
not use the UDP Tunnel Request extension when registering through an FA with
a co-located address unless the FA has the 'U' bit set, and that the MN
should set the 'R' bit in the extension in that case does indeed provide
enough information for the HA. Setting the 'F' bit does not add any information,
and supposing it is decided to still have the 'F' bit available, it should be
set in this case just for consistency - it is indeed not needed in this case.

( ... :-) I originally did not have the restriction that the MN must not 
add the extension in the non 'U' bit case, which led to the current text.)

Returning for a moment to another issue on which we know we disagree, I would
mention in the case of the HA processing load that even if we assume that
handling a mip re-registration requires many (10? 50?) times the processing power of
forwarding a mip packet, you will have keepalive re-registrations taking less
power than would be consumed by the same MN running 14400 bit/s of traffic.
And I believe the box should be sized so that it will be able to handle a
much larger traffic load than that, per user - so maybe the keepalive signalling,
which will only occur when you have no other traffic, is not such a heavy load
after all?

	Regards,
		Henrik

---

From: "Madhavi W. Chandra" <[email-masked]>
Date: Fri, 17 May 2002 14:18:40 -0400

Henrik,

On Tue, May 14, 2002 at 05:39:46PM +0200, Henrik Levkowetz wrote:
> Madhavi, you are right! and I apoligize. 

It's OK.  I'm glad that you agree now.

> The requirements that the MN should

True...I guess if the HA is a powerful box, it's not as big an issue.
However, given that this is not an absolute, I still think that a MAY
is more appropriate than a SHOULD.  A SHOULD is a rather strong 
suggestion.  I think your points can be made in the draft without the
strong SHOULD.

Regards,
Madhavi

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Fri, 17 May 2002 21:06:06 +0200

I wrote and Madhavi responded:
...<snip>...
> suggestion.  I think your points can be made in the draft without the

Well, then, on that point we still disagree. In view of the updated security
consideration section (posted a couple of days ago by Sami) I would think
it highly unadvisable to forego the use of registration requests as keepalives,
hence the SHOULD.

	Regards,
		Henrik