Subject: [mobile-ip] RE: RFC3220: Why allowing FA to reject RRQ with error code 136

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 29 Jun 2002 17:59:35 -0500

Hello Charlie,
It is hard to suggest a solution for the issue at hand without understanding
its background.
I admit that I did not search the archive for this issue. However, let me
give me guess here
and please correct me if I am wrong:

1. This may be applicable in the situation when we have a co-located HA.
FA & HA on the same box.
2. It also possible when the FA and the HA belongs to the same domain, 
like when we have dynamically allocated HA in the Foreign domain.

Am I guessing correctly here?

Also, please see two comments inline below

Regards,
Ahmad Muhanna

Hello Ahmad,

In the situation described in that paragraph, the mobile node
has used the "wrong" home agent address.  I thought the solution
was reasonable.  Perhaps the wording should be clarified
somewhere else, but if the mobility agent denies in this
circumstance, there is no chance for MN-HA anyway.  In
fact, I guess there's no chance whenever 136 is received.

<<START-1: Ahmad>>
Well, I am not sure if this is correct.
As per RFC2002 error code 136 is ONLY generated in the
case of MN trying to discover its HA or to dynamically allocate a HA.
However, RFC3220 added a new use for this code which generates the issue
at hand, as in section 3.7.2.

Now: When the MN tries to discover its HA, It is assumed that there
are multiple HA's and all of them can access the security association
between the Home domain and this MN. Otherwise, How these HA would
accept the RRQ to start with.
Therefore, in all circumistances when HA generates error code 136, it
MUST include MN-HA authentication extension. Otherwise, it would be in
violation of the same standard RFC2002(RFC3220), section 3.6.2.1 (b).
<<END-1: Ahmad>>

If you would like to suggest an improvement, that would
be nice.  Maybe the paragraph just doesn't belong there.

<<START-2 Ahmad>>
It is probably worth mentioning that the issue at hand is a very special
one.
We at a situation that the FA have some extra information about the IP
address
the MN included in the HA field in its RRQ message.
Let us refer to it as "WRONG HA" for sake of simplicity later on. 
The FA ,here, for sure knows that this IP address is an "INVALID Home Agent
Address" 
because it belongs to one of the interfaces of this FA.

NOW: If my guess mentioned above was correct then we have two possible
scenarios:
Scenario 1:
-----------
Wrong HA is one of the FA's interfaces IP addresses BUT this interface is
not a HA.

	1.1. 	Either allow the FA to forward this packet to this interface
anyway. 
		FA will never receive a RRP back and it will timeout and
send error 
		code 78 to the MN. "It is not a smart solution though also
hints to 
		MN that there is a network problem while there is none"
However, it 
		is real Registration timed out using the provided WRONG HA.
or,

	1.2. FA rejects the RRQ message and sends an appropriate error code
generated by the FA.

		- Reuse of error code 88 "HA Unreachable", BUT some people
may disagree 
		  because this will indicate to the MN that there is a
network problem 
		  while in reality there is none. However, it is real the
provided WRONG HA
		  is UNREACHABLE.

		- Reuse of error code 70 "Poorly formed Request" !!!

		- Probably we missed this initially. We have error code 77
"invalid care-of 
		  address". This scenaro is very similar the FA knows that
this is an invalid 
		  HA address. Why not creating a new FA error code, "INVALID
Home Agent Address".
	  	  Already deployed MN will NOT understand this, "backward
compatibility again".
	  	  BUT this is the best in my opinion.

Scenario 2:
-----------
Wrong HA is one of the FA's interfaces IP address AND this interface IS a HA
BUT NOT serving this MN.

	2.1. 	Either allow the FA to forward this packet to this interface
anyway. 
		HA will never recognize the MN and will discard the message.
		FA will never receive a RRP back and it will timeout and
send error 
		code 78 to the MN. "It is real, Registration timed out",

	2.2. same as in 1.2. above.

Conclusion:
I think the best is to create a new error code GENERATED by the FA "Invalid
Home Agent Address"

The second best in my opinion is to reuse error code 88. IT is very real,
the WRONG HA
address the MN provided is UNREACHABLE.
<<END-2 Ahmad>>

Thanks,
Ahmad       

Regards,
Charlie P.

Ahmad Muhanna wrote:

>
>
> Hello Charlie,
>
> I noticed that RFC3220 allows the FA to reject RRQ message with error
> code 136 as specified in paragraph 2 in section 3.7.2.
>
> This creates some conflicts as explained below:
> 1. In section 3.4. error code 136 is listed under "Registration denied
> by the home agent:"
>
> 2. In section 3.6.2.3., we read:
> "Code 136:  (Denied by home agent, Unknown home agent address)
> ....... "
>
> 3. Already deployed MN consider, as (RFC2002) RFC3220 define, that
> error code 136 is generated by the HA and expects to see MN-HA
> Authentication extension where FA ABSOLUTELY has no capabilities of
> generating.
>
> see section 3.6.2.1 (b).
>
> 4. MN are supposed to retransmit RRQ when receiving a RRP with error
> code of 136. It also assumed to use the IP address inserted in the HA
> IP address field in the RRP. see section 3.6.2.3.
>
> Apparently it is not the case when FA rejects the request with RRP
> message and error code 136!!!
>
> 5. I believe that keeping those error codes seperated as generated by
> FA and HA is very useful and I assume that was the intention to start
> with as stated in section 3.6.2. RFC2002(RFC3220).
>
> I believe this creates more problems than solving.
>
> Your clarification is greatly appreciated.
>
> Regards,
> Ahmad Muhanna