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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Wed, 21 Jun 2006 09:43:25 -0700

Hi Avi.  My understanding is that in this case, the HA will not be able
to send an RRP if it does not have an SA with the MN because this
message requires MN-HA AE.  The text state that if HA has an SA, then to
use that in the RRP.  Without an SA, the HA should drop the RRQ, IMHO.  

Kent 

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]] 
> Sent: Wednesday, June 21, 2006 8:13 AM
> To: Mobile IPv4 Mailing List
> Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails
> 
> Hi,
>  
> While working a scenario in WiMAX I have run into some 
> ambiguity in RFC3344.
>  
> The HA receives a Reg Request with MN-HA-AE and NAI extension 
> which it fails to authenticate.  In particular the HA cant 
> authenticate because it can't obtain the MN-HA from the AAA 
> using the NAI.
>  
> >From section 3.8.2.1 RFC3344 states that a Registration 
> Reply should be
> sent with code 131.
> 
> "if the Authenticator is invalid, the home agent MUST reject 
> the mobile node's registration and SHOULD send a Registration 
> Reply to the mobile node with Code 131"
> 
> And from section 3.6.2.1 describing the MN behavior we have:
>  
>    "If the Code field indicates an authentication failure, 
> either at the
>    foreign agent or the home agent, then it is quite possible that any
>    authenticators in the Registration Reply will also be in 
> error.  This
>    could happen, for example, if the shared secret between the mobile
>    node and home agent was erroneously configured.  The mobile node
>    SHOULD log such errors as security exceptions."
>  
> RFC3344 also states that Registration Reply MUST include a 
> MN-HA authentication extension:
>  
> Section 3.8.3.3 says  " Note that items (a) and (c) MUST 
> appear in every Registration Reply sent by the home agent."
>  
> where  (c) is  The Mobile-Home Authentication Extension.
>  
> The problem is that when MN-HA-AE fails at the HA there isnt 
> an available MN-HA authentication extension to use.  So how 
> can one send a registration reply?
> 
> Furthermore, if the HA cant not obtain an MN-HA for the 
> mobile, what should happen?
> 
> 
> Any help will be appreciated.
> 
> 
>  
>  
>  
> 
> ========================
> 
> Avi Lior                                    
> Bridgewater Systems Corporation
> Phone :  +1 (613) 591-9104 x6417
> Cell    :  +1 (613) 796-4183
> E-mail : mailto:[email-masked] 
> <mailto:[email-masked]>
> www.bridgewatersystems.com <http://www.bridgewatersystems.com/>  
> 
> 
> --
> 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: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 21 Jun 2006 14:38:17 -0400

All,

Simply not replying back to the MN won't prevent a malicious MN to send
zillions of bogus RRQs to the HA to launch an attack. If the MN has a
malicious intent, it can care less whether the HA replies or not.

Also, note that in most of the MIP4 deployments today, the MN has to go
through several levels of auth before it's messages are forwarded to the
HA. So, a completely untrusted MN pounding on the HA is a slim
possibility in these deployments. Therefore, I am less concerned about
dealing with MN's with malicious intent _at_ the HA.

OTOH, if the MN is not malicious, but for any reason failed auth at the
HA, the MN will have no clue why there is no RRP. Therefore, the MN will
send number of retries to the HA unnecessarily. From the current
deployments, we have seen many MNs go crazy and send numerous retries of
RRQ to the HA when they don't receive RRP within their retry timers.
These add unnecessarily load on the system. 

Lastly, RFC 3344 based mip4 is widely deployed today. If we need to
clarify something to better describe node behaviors, I am all for it.
However, changing basic protocol operation should be avoided as much as
possible.

Regards,
Kuntal

> From: Tsirtsis, George [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2006 12:51 PM
> To: Chowdhury, Kuntal; Kent Leung (kleung); Avi Lior; Mobile IPv4
Mailing
> List
> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator
fails
> 
> Usually it is not a good idea to be responding to messages that fail
> authentication because that can be used to mound DoS attacks. It is
> better to silently discard such messages.
> 
> The RFC also talks about authorization-enabling extensions and it is a
> bit unclear on which extensions qualify for that. Most people think of
> the MN-HA Authenticator to be an authentication-enabling extension.
> Others think that the MN-AAA Authenticator or even an FA-HA
> authenticator could play this role in some scenarios.
> 
> It would be nice not to loose this flexibility while clarifying the
> text.
> 
> George
> > From: Chowdhury, Kuntal [mailto:[email-masked]]
> > Sent: Wednesday, June 21, 2006 1:05 PM
> > To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List
> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator
> fails
> >
> > Kent/Avi,
> >
> > The current text does not say that the HA cannot send RRP when auth
> > fails. Rather it says that the HA "SHOULD" send RRP back to the MN:
> >
> > > if the Authenticator is invalid, the home agent MUST reject the
> > > mobile node's registration and SHOULD send a Registration Reply to
> the
> >
> > > mobile node with Code 131"
> >
> > What we need is a proper description of the HA and the MN behaviors
> when
> > the auth fails and the HA needs to send a RRP to stop the MN from
> > re-trying unnecessarily.
> >
> > The clarification could be:
> >
> > If the Authenticator is invalid, the home agent MUST reject the
mobile
> > node's registration and SHOULD send a Registration Reply to the
mobile
> > node with Code 131. In this case, the HA populates the MN-HA AE with
> all
> > 0s. Upon receiving the RRP with error code 131, the MN skips MN-HA
AE
> > validation and stops retrying registration attempts. The MN MAY log
> this
> > event in its internal log.
> >
> > What do you think?
> >
> > -Kuntal
> >
> > > From: Kent Leung (kleung) [mailto:[email-masked]]
> > > Sent: Wednesday, June 21, 2006 11:43 AM
> > > To: Avi Lior; Mobile IPv4 Mailing List
> > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
Authenticator
> > fails
> > > message requires MN-HA AE.  The text state that if HA has an SA,
> then
> > to
> > > >    foreign agent or the home agent, then it is quite possible
that
> > any
> > > >      Charter page:
> > http://www.ietf.org/html.charters/mip4-charter.html
> > >      Charter page:
> http://www.ietf.org/html.charters/mip4-charter.html
> >      Charter page:
http://www.ietf.org/html.charters/mip4-charter.html

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 22 Jun 2006 11:25:40 -0400

> From: Yoshi Tsuda (yotsuda) [mailto:[email-masked]]
> Sent: Thursday, June 22, 2006 2:27 AM
> To: Kent Leung (kleung); Henrik Levkowetz
> Cc: Mobile IPv4 Mailing List
fails
> 
> Hi Henrik,
> 
>  I have the same opinion with Kent; the RFC3344 has already
>  provided the method.
> 
>  And, I have another concern, if an HA or an FA should reply
>  an RRP to an MN even without having an SA:
>  - A malicious host could send an RRQ with any home address
>    or NAI to an HA or an FA.  Then, you know, the HA or the FA
>    needs to reply an RRP to the specified CoA, even if the host
>    of the CoA isn't using Mobile IP service.  This could produce
>    another kind of security problem. :(

[KC>] If the FA and the HA in the operator's network are widely exposed
to the internet, yeah what you describe is possible. However, I don't
believe we have too many of those types of operators out there who give
access to their FA and HA to anyone with a connection to the internet.
We can think of all sorts of scenarios, but we have to solve for the
most likely scenario, IMHO.

> Thanks.
> -Yoshi
> > From: Kent Leung (kleung)
> > Sent: Thursday, June 22, 2006 3:43 PM
> > To: Henrik Levkowetz
> > Cc: Mobile IPv4 Mailing List
> > Authenticator fails
> > Hi Henrik.  I think the protocol can already handle
> > authentication failures sufficiently.
> >
> > It's possible for MN to have multiple security contexts
> > (indexed by different SPIs) with the HA.  One could be used
> > for registration and the other for authenticating RRP with
> > error code 131.  So I believe RFC 3344 provides the mechanism
> > already.  As long as HA has an SA that can be used to protect
> > the RRP with the MN-HA AE, it can inform the MN such event
> > happened in a secure manner.
> >
> > I think mucking with the MN-HA AE is not good.  This can
> > create the situation when MN sends a valid RRQ, and MITM can
> > send a RRP with error code 131 and invalid MN-HA AE to the MN
> > immediately.  When the RRP is received, the MN will stop
> > retrying.  It's possible that the RRQ was lost in transit to
> > the HA.  And even if the valid RRP arrives later, MN may not
> > be able to associate with the any pending RRQ, which could
> > have been possibly removed since an associated RRP had been
> > received already.
> >
> > Kent
> >
> > > From: Henrik Levkowetz [mailto:[email-masked]]
> > > Sent: Wednesday, June 21, 2006 1:43 PM
> > > To: Kent Leung (kleung)
> > > Cc: Mobile IPv4 Mailing List
> > > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the
Authenticator
> > > fails
> > >
> > > Hi Kent,
> > >
> > > on 2006-06-21 19:13 Kent Leung (kleung) said the following:
> > > > If there is no SA, then I don't think HA should send a RRP.
> > >
> > > Maybe, but it leaves the MN and user with less information
> > than it/he
> > > could have.  I think that the best would be if we could find a
> > > standard way of handling this situation.
> > >
> > > Fwiw, this has come up before, we discussed how to handle this at
> > > ipUnplugged some time ago - it's a real situation when
> > you're setting
> > > up and deploying a network.
> > >
> > > Regards,
> > >
> > > 	Henrik
> > >
> > > > Kent
> > > >
> > > >> Sent: Wednesday, June 21, 2006 10:05 AM
> > > >> > the mobile node with Code 131"
> > > >>
> > > >> when the auth fails and the HA needs to send a RRP to
> > stop the MN
> > > >> from re-trying unnecessarily.
> > > >>
> > > >> the mobile node with Code 131. In this case, the HA
> > populates the
> > > >> MN-HA AE with all 0s. Upon receiving the RRP with error
> > > code 131, the
> > > >> MN skips MN-HA AE validation and stops retrying registration
> > > >> attempts. The MN MAY log this event in its internal log.
> > > >>
> > > >> What do you think?
> > > >>
> > > >> -Kuntal
> > > >>
> > > >> > Hi Avi.  My understanding is that in this case, the HA
> > > will not be
> > > >> > able to send an RRP if it does not have an SA with the
> > > MN because
> > > >> > this message requires MN-HA AE.  The text state that if HA
has
> > > >> an SA, then
> > > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the
> > > Authenticator
> > > >> > > fails
> > > >> > >
> > > >> > > Hi,
> > > >> > >
> > >  ambiguity
> > > >> > > in RFC3344.
> > > >> > > authenticate because it can't obtain the MN-HA from
> > > the AAA using the NAI.
> > > >> > >
> > > >> > > "if the Authenticator is invalid, the home agent MUST
> > > reject the
> > > >> > > mobile node's registration and SHOULD send a
> > > Registration  Reply
> > > >> > > to the mobile node with Code 131"
> > > >> > >
> > > >> > >    authenticators in the Registration Reply will also
> > > be  in error.
> > > >> > > This
> > > >> > > RFC3344 also states that Registration Reply MUST
> > > include a MN-HA
> > > >> > > authentication extension:
> > > >> > >
> > > >> > > Section 3.8.3.3 says  " Note that items (a) and (c)
> > > MUST  appear
> > > >> > > in every Registration Reply sent by the home agent."
> > > >> > >
> > > >> > > The problem is that when MN-HA-AE fails at the HA
> > > there isnt an
> > > >> > > available MN-HA authentication extension to use.  So
> > > how can one
> > > >> > > send a registration reply?
> > > >> > >
> > > >> > > Furthermore, if the HA cant not obtain an MN-HA for
> > > the  mobile,
> > > >> > > what should happen?
> > > >> > >
> > > >> > >
> > > >> > > =3D=======================
> > > >> > >
> > > >> > > Avi Lior
> > > >> > > Bridgewater Systems Corporation Phone :  +1 (613) 591-9104
> > > >> > > x6417
> > > >> > > Cell    :  +1 (613) 796-4183
> > > >> > >     Web interface:
> > https://www1.ietf.org/mailman/listinfo/mip4
> > > >> > >      Charter page:
> > > >> >     Web interface:
https://www1.ietf.org/mailman/listinfo/mip4
> > > >> "This email message and any attachments are confidential
> > > information
> > > >> of Starent Networks, Corp. The information transmitted
> > may not be
> > > >> used to create or change any contractual obligations of Starent
> > > >> Networks, Corp.  Any review, retransmission, dissemination
> > > or other
> > > >> use of, or taking of any action in reliance upon this
> > > e-mail and its
> > > >> attachments by persons or entities other than the intended
> > > recipient
> > > >> is prohibited. If you are not the intended recipient,
> > > please notify
> > > >> the sender immediately -- by replying to this message or
> > > by sending
> > > >> an email to [email-masked] -- and destroy
> > > all copies
> > > >> of this message and any attachments without reading or
> > disclosing
> > > >> their contents. Thank you."
> > > >>
> > > >
> > >
> > >
> >
> > --

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 22 Jun 2006 19:25:40 -0400

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

________________________________

From: Avi Lior [mailto:[email-masked]] 
Sent: Thursday, June 22, 2006 4:31 PM
To: Chowdhury, Kuntal; Behcet Sarikaya; Kent Leung (kleung)
Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator
fails

A rogue mobile can gain network access and then send bogus MIP Reg
Request totally masquerading the UDP packet. Only specialized
consideration in the access network can thwart that attack, otherwise
the bogus MIP Reg Request is off to the HA. 

As well, compromise of a network element in the Access Network could
also send MIP Reg Request especially if Proxy MIP is being used.

________________________________

	From: Chowdhury, Kuntal [mailto:[email-masked]] 
	Sent: Thursday, June 22, 2006 2:53 PM
	To: Behcet Sarikaya; Kent Leung (kleung)
	Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
	Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
Authenticator fails

	Yep...same case for other access technologies as well.  That
means, rogue mobiles sending bogus RRQ packets to the HA is extremely
slim.

	-Kuntal

________________________________

	From: Behcet Sarikaya [mailto:[email-masked]] 
	Sent: Thursday, June 22, 2006 1:06 PM
	To: Chowdhury, Kuntal; Kent Leung (kleung)
	Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
	Subject: Re: [Mip4] 3344 Sending a Reg Reply when the
Authenticator fails

	Hi Kuntal
	  In WiMAX, if MS fails EAP authentication, it is out, it cannot
even send an RREQ.
	
	Regards,
	
	Behcet

	----- Original Message ----
	From: "Chowdhury, Kuntal" <[email-masked]>
	To: Kent Leung (kleung) <[email-masked]>
	Cc: Mobile IPv4 Mailing List <[email-masked]>; Henrik Levkowetz
<[email-masked]>
	Sent: Thursday, June 22, 2006 10:48:03 AM
	Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
Authenticator fails

	> Sent: Thursday, June 22, 2006 1:43 AM
	> To: Henrik Levkowetz
Authenticator
	fails
	> Hi Henrik.  I think the protocol can already handle
authentication
	> failures sufficiently.
(indexed by
	> different SPIs) with the HA.  One could be used for
registration and
	the
	> other for authenticating RRP with error code 131.  So I
believe RFC
	3344
	> provides the mechanism already.  As long as HA has an SA that
can be
	> used to protect the RRP with the MN-HA AE, it can inform the
MN such
	> event happened in a secure manner.
	> 
create the
	> situation when MN sends a valid RRQ, and MITM can send a RRP
with
	error
	> code 131 and invalid MN-HA AE to the MN immediately.  When the
RRP is
	> received, the MN will stop retrying.  It's possible that the
RRQ was
	> lost in transit to the HA.  And even if the valid RRP arrives
later,
	MN
	> may not be able to associate with the any pending RRQ, which
could
	have
	> been possibly removed since an associated RRP had been
received
	already.
	[KC>] If the HA does not send RRP back to the MN, as you
initially
	suggested, the MN will keep retrying. That is not good either.
	
	Look at other protocols. For example EAP, if auth fails, the
	authenticator MUST send back a failure packet to the peer. Same
case for
	other protocols over UNI. So, I am wondering why the paranoids
are not
	concerned about MiTM and DoS attacks in general!
	
	Regarding your comment "mucking with the MN-HA AE is not good",
if MN-HA
	AE is not absolutely necessary in the RRP messages, I will be
more than
	happy to propose that when code 131 is included, the RRP
contains no
	MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you
have a
	better suggestion that does not break current implementations,
and does
	not produce a new mip4 protocol, I don't think we have a choice
here.

	> > than it/he could have.  I think that the best would be if we
	> > could find a standard way of handling this situation.
	> >
	> > Fwiw, this has come up before, we discussed how to handle
	> > this at ipUnplugged some time ago - it's a real situation
	> > when you're setting up and deploying a network.
	> >
	> > Regards,
	> >
	> >     Henrik
	> >
	> > > Kent
	> > >
	> > >> fails. Rather it says that the HA "SHOULD" send RRP back
to the
	MN:
	> > >>
	> > >> > if the Authenticator is invalid, the home agent MUST
reject
	the
	> > Registration Reply to
stop the MN
	> > >> mobile node's registration and SHOULD send a Registration
Reply
	to
populates the
	> > >> > this message requires MN-HA AE.  The text state that if
HA has
may not be
disclosing

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 23 Jun 2006 12:52:30 -0400

Sure we can say that the HA is allowed to send RRP on auth failure. What
you cite here is talking about how the MN processes the RRP. It does not
say anything about allowing or disallowing the HA to send RRP on auth
failure. 

As I have been saying all along...all we need is to clarify the node
behaviors better for error case handling. The current text does a poor
job on describing the error handling cases. 

-Kuntal

From: Venkateshwara Sastry (vsastry) [mailto:[email-masked]] 
Sent: Friday, June 23, 2006 2:19 AM
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

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Sat, 24 Jun 2006 10:02:18 -0700

BTW, there are many places where authentication is specified as "MUST".

1) This section says the registration messages must be authenticated
between MN and HA.
 
3.2. Authentication
 
   "Registration messages between
   a mobile node and its home agent MUST be authenticated with an
   authorization-enabling extension, e.g. the Mobile-Home Authentication
   Extension (Section 3.5.2)."
 
2) This section says that the authenticator value must protect the
message.
 
3.5.1. Computing Authentication Extension Values

   The Authenticator value computed for each authentication Extension
   MUST protect the following fields from the registration message:

      -  the UDP payload (that is, the Registration Request or
         Registration Reply data),

      -  all prior Extensions in their entirety, and

      -  the Type, Length, and SPI of this Extension.
 
3) This section says MHAE must be present in message.
 
3.5.2. Mobile-Home Authentication Extension

   Exactly one authorization-enabling extension MUST be present in all
   Registration Requests, and also in all Registration Replies generated
   by the Home Agent.  The Mobile-Home Authentication Extension is
   always an authorization-enabling for registration messages specified
   in this document. 
 
4) This section says MHAE must be in RRP.
 
c) The Mobile-Home Authentication Extension,
 
  Note that items (a) and (c) MUST appear in every Registration Reply
   sent by the home agent.
 
5) This section says MN must check the authenticator value and discard
reply if it's invalid.
 
3.6.2.1. Validity Checks
 
         MUST silently discard the Reply 
 
I think valid authentication is pretty important before any entity
changes its 
operation based on the message.  Logging a security violation is not
considered 
a change in the registration logic, IMHO.  But stopping registration
retransmission 
surely is.
 
Kent

	From: Chowdhury, Kuntal [mailto:[email-masked]] 
	Sent: Friday, June 23, 2006 9:53 AM
	To: Venkateshwara Sastry (vsastry); Avi Lior
	Cc: Mobile IPv4 Mailing List
	Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
Authenticator fails

	Sure we can say that the HA is allowed to send RRP on auth
failure. What you cite here is talking about how the MN processes the
RRP. It does not say anything about allowing or disallowing the HA to
send RRP on auth failure. 

	As I have been saying all along...all we need is to clarify the
node behaviors better for error case handling. The current text does a
poor job on describing the error handling cases. 

	-Kuntal

	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

---

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

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

> Sent: Monday, June 26, 2006 8:38 AM
> To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
> 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?
>  
>  
> 
> 
> 
> 	Sent: Friday, June 23, 2006 4:19 PM
> 	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.
> 		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
> 
> 		 
> 
>

---

From: "Venkateshwara Sastry \(vsastry\)" <[email-masked]>
Date: Mon, 26 Jun 2006 12:26:49 +0530

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

> From: Yoshi Tsuda (yotsuda) 
> Sent: Monday, June 26, 2006 10:31 AM
> To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
>  Personally, I believe, an MN should stop sending RRQs,  if 
> it receives an RRP with 131, and if the MN has sent the  
> 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
> 
> > I think the protocol does allow an HA to respond with an 
> auth failure.  
> > Code 131 was designed for that no?
> >  
> 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?
> >  
> to respond on 
> > auth failure. If HA responding on auth failure was really the 
> > 	      b) If the Code field indicates that service is 
> denied by the 
> > home
> registration 
> > was
> > 	         in the Extension.  If the Registration Reply 
> was generated 
> > by
> > 	         the home agent but no Mobile-Home 
> Authentication Extension 
> > is
> > 	         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
> > 
> > 
> > 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.
> > 
> > 		 
> > 
> fails, should the HA 
> allows the HA to send a 
> > 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
> > 
> > 		 
> > 
> > 
>

---

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

Yes, 131 is the error code indicating the authentication failed.  As
Sastry pointed out, this could be the case that data corruption occurred
along the way.  So when HA has an SA, it should send the RRP which is
protected by MHAE.  In this case, MN can authenticate the message
properly.
 
For example, let's say there are 2 SAs between MN and HA.  If HA fails
to authenticate the RRQ, it would be wise for HA to use the other SA to
send the RRP.
 
Kent

	Sent: Sunday, June 25, 2006 4:38 PM

	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?

	<snip>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 29 Jun 2006 03:31:20 -0400

Separate SA for each direction i.e. SA1 for RRQ processing, and SA2 for
RRP processing is an implementation specific detail, IMHO. MIP4 protocol
in RFC3344 allows that, no?

-Kuntal

Sent: Monday, June 26, 2006 6:31 AM

Kent

	<snip>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 29 Jun 2006 03:34:19 -0400

"A configurable counter could be maintained at the HA to restrict the
number of repeated RRPs with a Code 131 for the same MN. "

I agree with this statement. Furthermore, this can be a configuration
option in the HA and mip4 protocol need not change to accommodate this.

-Kuntal

From: Sebastian Thalanany [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 3:48 AM
To: Yoshi Tsuda (yotsuda)
Cc: Venkateshwara Sastry (vsastry); Avi Lior; Chowdhury, Kuntal; Mobile
IPv4 Mailing List
Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator
fails

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

Yoshi Tsuda (yotsuda) wrote:

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
		 
		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.  

			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?

			 

			    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

		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

			 
			            -Kuntal