Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails

From: "Yoshi Tsuda \(yotsuda\)" <[email-masked]>
Date: Mon, 26 Jun 2006 16:00:54 +0800

Hi Sastry,

 Oh, I see.  Thank you for your pointing out the case.
 Then, I should have written the conditions like the following:
 a) An MN should stop sending RRQs,
 a-1) if it receives an RRP with 131,
 a-2) and if auth check fails,
 a-3) and if the MN has sent the original RRQ.
 <- This might be caused due to key differences between
     an HA and an MN.  But, according to the current rfc3344,
     an MN can continue sending such RRQs.

 b) An MN can re-send an RRQ,
 b-1) if the MN receives an RRP with 131,
 b-2) and if auth check succeeds,
 b-3) and if the MN has sent the original RRQ.
 <- This might be caused due to a corrupted RRQ.

 This kind of description about error handling, other than 69,
 133, 136 and so on, isn't so clear in rfc3344, I'm afraid.

Best regards.
-Yoshi

> -----Original Message-----
> From: Venkateshwara Sastry (vsastry) 
> Sent: Monday, June 26, 2006 3:57 PM
> To: Yoshi Tsuda (yotsuda); 'Avi Lior'; 'Chowdhury, Kuntal'
> Cc: 'Mobile IPv4 Mailing List'
> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the 
> Authenticator fails
> 
> IMHO, if RRQ authentication failed at HA(may be packet was 
> corrupted when received by HA), and HA HAS a SA with that MN, 
> the HA can send an RRP with MHAE and error code 131. In such 
> a sceanrio, there is a possibility that MN can authenticate 
> the RRP and continue further processing.
> 
> Regards
> Sastry
> 
> > -----Original Message-----
> > From: Yoshi Tsuda (yotsuda)
> > Sent: Monday, June 26, 2006 10:31 AM
> > To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
> > Cc: Mobile IPv4 Mailing List
> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator 
> > fails
> > 
> > Hi Avi and all,
> > 
> >  Good point.
> > 
> >  Personally, I believe, an MN should stop sending RRQs,  if it 
> > receives an RRP with 131, and if the MN has sent the 
> original RRQ in 
> > spite of the meaning of "silently discard".
> >  The term, "silently discard" found to be used in rfc2002, 
> too; so it 
> > might have a histrical reason, though...
> > 
> >  Also, I agree with Kuntal that error handlings haven't been well 
> > documented.  If this causes deployment issues,  should we 
> have a new 
> > I-D about handling codes or ask  modifications of rfc3344 to the 
> > inventor of MIP?
> > 
> > Thanks.
> > -Yoshi
> > 
> > > -----Original Message-----
> > > From: Avi Lior [mailto:[email-masked]]
> > > Sent: Monday, June 26, 2006 8:38 AM
> > > To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
> > > Cc: Mobile IPv4 Mailing List
> > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the 
> Authenticator 
> > > fails
> > > 
> > > I think the protocol does allow an HA to respond with an
> > auth failure.  
> > > Code 131 was designed for that no?
> > >  
> > > However, as you point out an MN receiving a RRP which fails
> > its auth
> > > check MUST silently discard.  Silently discard means no more 
> > > processing.  Does that mean that the MN is not allowed to use the 
> > > receipt of the RRP to stop sending any further RRQs?  Some
> > would say
> > > yes.
> > >  
> > > Therefore, why allow the HA to send an RRP when clearly 
> the MN will 
> > > silently discard it?
> > >  
> > > Is this a contradiction or is it by design?
> > >  
> > >  
> > > 
> > > 
> > > 
> > > ________________________________
> > > 
> > > 	From: Venkateshwara Sastry (vsastry) [mailto:[email-masked]] 
> > > 	Sent: Friday, June 23, 2006 4:19 PM
> > > 	To: Chowdhury, Kuntal; Avi Lior
> > > 	Cc: Mobile IPv4 Mailing List
> > > 	Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator
> > > fails
> > > 	
> > > 	
> > > 	We can not really claim that current protocol allows HA
> > to respond on
> > > auth failure. If HA responding on auth failure was really the 
> > > intention of the designers, silently discarding such
> > packets by MN as
> > > indicated in following text does not make sense.
> > > 	      b) If the Code field indicates that service is
> > denied by the
> > > home
> > > 	         agent, or if the Code field indicates that the
> > registration
> > > was
> > > 	         accepted by the home agent, exactly one Mobile-Home
> > > 	         Authentication Extension MUST be present in
> > the Registration
> > > 	         Reply, and the mobile node MUST check the
> > Authenticator
> > > value
> > > 	         in the Extension.  If the Registration Reply
> > was generated
> > > by
> > > 	         the home agent but no Mobile-Home
> > Authentication Extension
> > > is
> > > 	         found, or if more than one Mobile-Home Authentication 
> > > Extension
> > > 	         is found, or if the Authenticator is invalid,
> > the mobile
> > > node
> > > 	         MUST silently discard the Reply and SHOULD log
> > the event as
> > > a
> > > 	         security exception.
> > > 	
> > > 	Regards
> > > 	Sastry
> > > 
> > > 
> > > ________________________________
> > > 
> > > 		From: Chowdhury, Kuntal
> > > [mailto:[email-masked]] 
> > > 		Sent: Friday, June 23, 2006 4:56 AM
> > > 		To: Avi Lior
> > > 		Cc: Mobile IPv4 Mailing List
> > > 		Subject: RE: [Mip4] 3344 Sending a Reg Reply
> > when the Authenticator
> > > fails
> > > 		
> > > 		
> > > 
> > > 		Avi,
> > > 
> > > 		 
> > > 
> > > 		If a rogue MN can break into the network (i.e. 
> > > pass access auth), anything is possible. However, by
> > putting multiple
> > > levels of auth (at least 1 or 2); the operators make this
> > possibility
> > > extremely slim. So, let's not get hung-up with the fact
> > that rouge MNs
> > > can do bad things.
> > > 
> > > 		 
> > > 
> > > 		The issue is simple: if the auth of a RRQ
> > fails, should the HA
> > > respond back to the MN? There are some people who believe a
> > response
> > > should be sent. There are some who believe that the HA
> > should silently
> > > discard the packet.
> > > 
> > > 		 
> > > 
> > > 		In this context, the current mip4 protocol
> > allows the HA to send a
> > > response upon auth failure. The current text also allows those HA 
> > > implementations which like to silently discard the packet.
> > So, let's
> > > not change the protocol as it allows both the 
> > > behaviors/implementations. We can just clarify some text to
> > describe
> > > how the response packet is formatted.
> > > 
> > > 		 
> > > 
> > > 		-Kuntal
> > > 
> > > 		 
> > > 
> > > 
> > 
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Sebastian Thalanany <[email-masked]>
Date: Mon, 26 Jun 2006 03:47:59 -0500

Hi Yoshi,

                Good points in this thread pertaining to the behavior 
associated with Code 131.

                A silent discard of the RRP, at the MN, in the case of 
Code 131 is reasonable to avoid further RRQs that do not contain the MHAE.

                However, if an RRP containing Code 131 was generated by 
the HA, it is possible that it is a result of a corruption of the 
original RRQ, over the wireless link. In this case it is reasonable for 
the MN to use the receipt of an RRP with Code 131 to trigger a new RRP. 
A configurable counter could be maintained at the HA to restrict the 
number of repeated RRPs with a Code 131 for the same MN.

                 Thanks.

Regards,
    Sebastian