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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 26 Jun 2006 04:19:36 -0700

That's been my point.  HA sends the RRP with MHAE when it _has_ an SA
with the MN.  So if administrator wants the HA to be able to inform the
MN that the registration SA (key) is wrong, then set up a default SA to
communicate this event securely.  This mechanism would be already
covered in current RFC 3344 without protocol changes.

Kent 

> -----Original Message-----
> From: Venkateshwara Sastry (vsastry) 
> Sent: Sunday, June 25, 2006 11: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/
> 

-- 
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 08:13:44 -0500

Hi Kent,
                  If the corruption of the RRQ has occurred, as a result 
of a loss of integrity of the wireless link (MN and HA have a security 
association), then the RRP with a Code 131 should be processed (not 
limited to discarding and error logging) further by the MN to re-send an 
RRQ.  To accommodate this scenario, the HA could avoid sending an RRP, 
when the MN and HA do not have a security association.

Regards,
     Sebastian