Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code 132 - foreign agent failed authentication

From: Acee Lindem <[email-masked]>
Date: Fri, 4 Apr 2008 15:01:52 -0400

Any opinions?
Thanks,
Acee
On Mar 21, 2008, at 10:49 AM, Acee Lindem wrote:

> With respect to our MIP4 HA implementation, we've had several  
> discussions as to whether a registration reply should be generated  
> when the registration request fails FA-HA authentication. The  
> existence of the 132 reply code would imply that one should always  
> respond. However, this is contrary to way authentication works in  
> most protocols (at least routing protocols) and would seem to leave  
> the HA more susceptible to DoS attacks. I checked the RFC 3344 BIS  
> draft and there has been no change in this area.
> Thanks,
> Acee

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

---

From: "Yoshi Tsuda (yotsuda)" <[email-masked]>
Date: Sat, 5 Apr 2008 10:05:46 +0800

Hi Acee,

 The 3.8.2.1 section of rfc3344 doesn't mandate for an HA to reply
 an RRP to an MN with 132, but it just says an HA "should" send
 an RRP to an MN with 132.
 Thus, you have the option not to send an RRP to an MN based on
 your policy against DoS attacks.  You know, an rfc doesn't define
 a specific policy, but mechanism.  So, I believe, the original rfc
 works fine.

Cheers.
-Yoshi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Acee Lindem
> Sent: Friday, April 04, 2008 12:02 PM
> Cc: Mobile IPv4 Mailing List
> Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code 
> 132 - foreignagent failed authentication
> 
> Any opinions?
> Thanks,
> Acee
> > respond. However, this is contrary to way authentication 
> works in most 
> > protocols (at least routing protocols) and would seem to 
> leave the HA 
> > more susceptible to DoS attacks. I checked the RFC 3344 BIS 
> draft and

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 05 Apr 2008 21:48:21 +0200

Hi Acee,

Your post sums it up pretty much, but let me add this:  In some
situations and deployments, mainly when you're setting up a new
deployment environment, you actually want to generate the replies
for debugging and informative purposes, while mostly you want to
turn them off to avoid DoS attacks.  At least one HA implementation
I know has the behaviour configurable, for that reason.  And as
the RFC 3344 and 3344bis text seems to match this usage reasonably
well, I don't think we want to change it?

	Henrik

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 7 Apr 2008 10:41:58 +0100

Hi all,

 I have the following comments you may want to consider:

1) The SHOULD language is very strong. SHOULD in an RFC means that the
IETF thinks that the procedure should be followed by all
implementations unless the implementor has a very good reason not to
do so. In other words, and in this case, the RFC says that the IETF
thinks HAs should send these 131(MN auth failed)/132(FA auth failed)
codes, although not sending them does not break interoperability.

The recent discussion indicates that we are not so sure that this is
the correct course of "default" action. On the contrary one should
think carefuly if there is a potential DoS attack in a given
implementation/deployment and then decide whether such messages should
be sent. If that is what we think then the correct language in that
"the HA SHOULD NOT send RREP messages" in this case.

2) If MN-HA auth fails notify the FA! What I think would make most
sense is something like the following::

-  if MN-FA auth fails:
 "the HA MUST discard the message and SHOULD NOT send any response."

- If the MN-FA auth fails, however:
 "the HA MUST discard the message and MAY send a response (with code
131) to the FA if one exists, otherwise the HA SHOULD NOT send any
response"

I think sending a message to the FA when the MN-HA auth fails makes
sense don't you?

Again I am not sure if RFC3344bis can acommodate such change, since
this would require FAs to understand code 131, which may not do
currently. Still I do not think this would really break any
implementation, Most likely an FA would just log the error, not
knowing what to do next beyond understanding this as a rejection.

Thoughts?
George

2008/4/5 Henrik Levkowetz <[email-masked]>:
> discussions as to whether a registration reply should be generated  when the
> registration request fails FA-HA authentication. The  existence of the 132
> reply code would imply that one should always  respond. However, this is
> contrary to way authentication works in  most protocols (at least routing
> protocols) and would seem to leave  the HA more susceptible to DoS attacks.
> I checked the RFC 3344 BIS  draft and there has been no change in this area.
> > > Thanks,
> > > Acee
> > >
> >
> >
>
>
> --

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 7 Apr 2008 16:48:54 +0100

See a correction below (Thanks to Ahmad for spotting the mistake)

>  sense is something like the following::

GT> This should have been:
 - If the FA-HA auth fails, however

>  - If the MN-FA auth fails, however:

GT> This should have been:

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 7 Apr 2008 11:36:02 -0500

George, let me understand what you are trying to say:

1. If FA-HA authentication fails, then HA MUST discard the message and
HA SHOULD not send any response. This is irrelevant to what happens with
MN-HA AE, because if FA-HA fails there is no point to validate MN-HA AE.

2. If MN-HA AE fails, then?

2.1. Does this mean that FA-HA AE was present and was successfully
processed? If yes, it makes a lot of sense to send a RRP to the MN with
code 131.

2.2. Id FA-HA AE is not there, then probably it is less stronger for the
HA to send RRP with an error code 131. However, sending RRP with error
code in normal case is very useful. I agree that MN and HA should be in
sync but there is a possibility for errors and there is nothing wrong to
inform the MN whenever safe and necessary.

However, in general, I support leaving RFC3344 wording as is. Why?

I agree with George on the definition of SHOULD. BUT what more of a
reason than a DoS attack for the HA not to send a RRQ with error code
131 or any other code. I would rather leave it to implementation rather
than go through every single scenario and document it here. Back to the
same discussion, let us leave some room for those architect to do some
work and identify how their HA will address DoS attack. There are many
ways to do it and at the same time continue to satisfy the SHOULD as per
RFC3344.

My 2 cents.

Regards,
Ahmad

> Behalf Of George Tsirtsis
> Sent: Monday, April 07, 2008 10:49 AM
> To: Henrik Levkowetz
> Cc: Mobile IPv4 Mailing List; Acee Lindem
> 132 - foreign agent failed authentication
> 
> >  1) The SHOULD language is very strong. SHOULD in an RFC means that 
> > the  IETF thinks that the procedure should be followed by all  
> >  >  Your post sums it up pretty much, but let me add this:  
> In some  >  
> > situations and deployments, mainly when you're setting up a new  >  
> > deployment environment, you actually want to generate the 
> replies  >  
> > for debugging and informative purposes, while mostly you 
> want to  >  
> > turn them off to avoid DoS attacks.  At least one HA 
> implementation  >  
> > I know has the behaviour configurable, for that reason.  And as  >  
> > the RFC 3344 and 3344bis text seems to match this usage 
> reasonably  >  
> > when the  > registration request fails FA-HA authentication. The  
> > existence of the 132  > reply code would imply that one 
> should always  
> > respond. However, this is  > contrary to way authentication 
> works in  
> > most protocols (at least routing  > protocols) and would 
> seem to leave  the HA more susceptible to DoS attacks.
> >  >      Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html
> >  >  Supplemental site: http://www.mip4.org/  >  >
> >
> --

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 7 Apr 2008 17:48:34 +0100

>  MN-HA AE, because if FA-HA fails there is no point to validate MN-HA AE.

GT> Yes

>  processed? If yes, it makes a lot of sense to send a RRP to the MN with

GT> Not exactly. What I am saying is that in this case the HA should
notify the FA (not the MN!). Remember the MN may be an attacker in
which case the FA needs to be notified of that possibility.

>  HA to send RRP with an error code 131.

GT> I still think that if it is known that an FA exists (whether FA-HA
AE is used or not) it is useful to notify the FA (again not the MN).

> However, sending RRP with error

GT> Of course sending RRP with error codes e.g., if the timestamp is
wrong or some other reason is very important....here we are just
talking about the special case of authentication failures.

>  ways to do it and at the same time continue to satisfy the SHOULD as per

GT> I think if people are not comfortable with describing in
RFC3344bis the behavior I argue for above, at least the SHOULD, should
be changed to MAY or even SHOULD NOT, depending how strong a message
we want to give. Note that non of these changes breaks existing
implementations. To break existing implementation we would have to
change this to MUST NOT.

Tegards
George

---

From: Acee Lindem <[email-masked]>
Date: Mon, 7 Apr 2008 14:06:27 -0400

I'd support this change in RFC 3344.
Thanks,
Acee

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 7 Apr 2008 11:10:41 -0700

Isn't there a significantly higher chance of DoS attacks from MNs (i.e.
invalid MN-HA Auth Ext) than from FAs (i.e. invalid FA-HA Auth Ext)?
When FA-HA authentication fails, it's usually due to misconfiguration.
Of course, a rogue MN can append FA-HA Auth Ext in the request.  

I've always preferred not to send reply when authentication failed by
only logging the event.  But then always runs into cases when the reply
was required.  So I think it's up to implementation to decide the
sending of the RRP or not when authentication fails.  Not sure if
changing the RFC is necessary.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Acee Lindem
Sent: Friday, April 04, 2008 12:02 PM
Cc: Mobile IPv4 Mailing List
Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code 132 -
foreignagent failed authentication

Any opinions?
Thanks,
Acee
On Mar 21, 2008, at 10:49 AM, Acee Lindem wrote:

> respond. However, this is contrary to way authentication works in most

> protocols (at least routing protocols) and would seem to leave the HA 
> more susceptible to DoS attacks. I checked the RFC 3344 BIS draft and 
> there has been no change in this area.
> Thanks,
> Acee

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 7 Apr 2008 11:18:34 -0700

Hi George.  I'm not clear by "sending a message to the FA when MN-HA
auth fails"?  Is this the RRP with error code 131?  If so, does the FA
forward the RRP to the MN?

Or the intention is to only notify the FA and not the MN to avoid DoS
attack?  

What happens if the MN is appending the FA-HA auth ext?

Today, FA already receive error code 131 when MN-HA auth failed if the
HA is sending the RRP.  I'm not sure what's new here.  
  
Kent 

-----Original Message-----
George Tsirtsis
Sent: Monday, April 07, 2008 2:42 AM

Hi all,

1) The SHOULD language is very strong. SHOULD in an RFC means that the
IETF thinks that the procedure should be followed by all implementations
unless the implementor has a very good reason not to do so. In other
words, and in this case, the RFC says that the IETF thinks HAs should
send these 131(MN auth failed)/132(FA auth failed) codes, although not
sending them does not break interoperability.

The recent discussion indicates that we are not so sure that this is the
correct course of "default" action. On the contrary one should think
carefuly if there is a potential DoS attack in a given
implementation/deployment and then decide whether such messages should
be sent. If that is what we think then the correct language in that "the
HA SHOULD NOT send RREP messages" in this case.

2) If MN-HA auth fails notify the FA! What I think would make most sense
is something like the following::

-  if MN-FA auth fails:

Again I am not sure if RFC3344bis can acommodate such change, since this
would require FAs to understand code 131, which may not do currently.
Still I do not think this would really break any implementation, Most
likely an FA would just log the error, not knowing what to do next
beyond understanding this as a rejection.

Thoughts?
George

2008/4/5 Henrik Levkowetz <[email-masked]>:
> deployment environment, you actually want to generate the replies  for

> debugging and informative purposes, while mostly you want to  turn 
> them off to avoid DoS attacks.  At least one HA implementation  I know

> has the behaviour configurable, for that reason.  And as  the RFC 3344

> and 3344bis text seems to match this usage reasonably  well, I don't 
> think we want to change it?
>
>
>         Henrik
>
> most protocols (at least routing

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 7 Apr 2008 14:10:16 -0500

George,

Is there a mechanism in RFC3344 or anywwhere else that the HA can send a
RRP that only destined to the FA?
I am not aware of that functionality, could you please explain.

Thanks.

Regards,
Ahmad

> From: George Tsirtsis [mailto:[email-masked]] 
> Sent: Monday, April 07, 2008 11:49 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Henrik Levkowetz; Mobile IPv4 Mailing List; Acee Lindem
> >  1. If FA-HA authentication fails, then HA MUST discard the message 
> > and  HA SHOULD not send any response. This is irrelevant to what 
> > happens with  MN-HA AE, because if FA-HA fails there is no 
> point to validate MN-HA AE.
> >
> 
> GT> Yes
> 
> > processed? If yes, it makes a lot of sense to send a RRP to the MN 
> > with  code 131.
> >
> 
> notify the FA (not the MN!). Remember the MN may be an 
> attacker in which case the FA needs to be notified of that 
> possibility.
> 
> >  2.2. Id FA-HA AE is not there, then probably it is less 
> stronger for 
> > the  HA to send RRP with an error code 131.
> 
> >  code in normal case is very useful. I agree that MN and HA 
> should be 
> > in  sync but there is a possibility for errors and there is nothing 
> > wrong to  inform the MN whenever safe and necessary.
> >
> 
> wrong or some other reason is very important....here we are 
> just talking about the special case of authentication failures.
> 
> >  131 or any other code. I would rather leave it to implementation 
> > rather  than go through every single scenario and document it here. 
> > Back to the  same discussion, let us leave some room for those 
> > architect to do some  work and identify how their HA will 
> address DoS 
> > attack. There are many  ways to do it and at the same time 
> continue to 
> > satisfy the SHOULD as per  RFC3344.
> >
> 
> RFC3344bis the behavior I argue for above, at least the 
> SHOULD, should be changed to MAY or even SHOULD NOT, 
> depending how strong a message we want to give. Note that non 
> of these changes breaks existing implementations. To break 
> existing implementation we would have to change this to MUST NOT.
> 
> Tegards
> George
> >
> >
> >  > From: [email-masked] [mailto:[email-masked]] On  > 
> >  > Cc: Mobile IPv4 Mailing List; Acee Lindem  > Subject: Re: [Mip4] 
> > RFC 3344 - Home Agent Registration Code  > 132 - foreign 
> agent failed 
> > authentication  >
> >
> >
> >  > On Mon, Apr 7, 2008 at 10:41 AM, George Tsirtsis  > 
> >  > >  1) The SHOULD language is very strong. SHOULD in an RFC means 
> > that  > > the  IETF thinks that the procedure should be followed by 
> > all  > > implementations unless the implementor has a very good  > 
> > reason not to  > > do so. In other words, and in this case, the RFC 
> > says that  > the IETF  > > thinks HAs should send these 131(MN auth 
> > failed)/132(FA  > auth failed)  > > codes, although not 
> sending them 
> >  > >  The recent discussion indicates that we are not so 
> sure  > that 
> > this is  > > the correct course of "default" action. On the 
> contrary 
> > one should  > > think carefuly if there is a potential DoS 
> attack in a 
> > given  > > implementation/deployment and then decide 
> whether such  > 
> > messages should  > > be sent. If that is what we think then the 
> > correct language  > in that  > > "the HA SHOULD NOT send RREP 
> > messages" in this case.
> >  > >
> >  > >  2) If MN-HA auth fails notify the FA! What I think 
> would  > make 
> > most  > > sense is something like the following::
> >  > >
> >  > >  -  if MN-FA auth fails:
> >  >
> >  >  - If the FA-HA auth fails, however  >
> >  > >  131) to the FA if one exists, otherwise the HA SHOULD NOT  > 
> > send any  > > response"
> >  > >
> >  > >  I think sending a message to the FA when the MN-HA 
> auth  > fails 
> > makes  > > sense don't you?
> >  > >
> >  > >  Again I am not sure if RFC3344bis can acommodate such 
>  > change, 
> > since  > > this would require FAs to understand code 131, which may 
> > not do  > > currently. Still I do not think this would really break 
> > any  > > implementation, Most likely an FA would just log 
> the error, 
> > not  > > knowing what to do next beyond understanding this as a 
> > rejection.
> >  > >
> >  > >  Thoughts?
> >  > >  George
> >  > >
> >  > >
> > >  > > deployment environment, you actually want to generate the  > 
> > replies  >  > > for debugging and informative purposes, 
> while mostly 
> > you  > want to  >  > > turn them off to avoid DoS attacks.  
> At least 
> > one HA  > implementation  >  > > I know has the behaviour 
> > configurable, for that reason.  And as  >  > > the RFC 3344 and 
> > 3344bis text seems to match this usage  > reasonably  >  > 
> > well, I 
> >  > >  > > > With respect to our MIP4 HA implementation, 
> we've  > had 
> > several  > > > discussions as to whether a registration 
> reply should 
> > be  > generated  > > when the  > registration request fails FA-HA 
> > authentication. The  > > existence of the 132  > reply code would 
> > imply that one  > should always  > > respond. However, this is  > 
> > contrary to way authentication  > works in  > > most protocols (at 
> > least routing  > protocols) and would  > seem to leave  the HA more 
> > susceptible to DoS attacks.
> >  > >  > I checked the RFC 3344 BIS  draft and there has been no  > 
> > change in this area.
> >  > >  > > > Thanks,
> >  > >  > > > Acee
> >  > >  > > >
> >  > >  > >
> >  > >  > >
> >  > >  >
> >  > >  >
> >  > >  > --
> >  > >
> >  > >
> >  > >  >     Web interface: 
> https://www.ietf.org/mailman/listinfo/mip4
> >  > >  >      Charter page:
> >  > >  >  Supplemental site: http://www.mip4.org/  >  >  > >  > --
> >
> >
> >  > Supplemental site: http://www.mip4.org/  >
> >
>

---

From: Acee Lindem <[email-masked]>
Date: Mon, 7 Apr 2008 21:27:18 -0400

> invalid MN-HA Auth Ext) than from FAs (i.e. invalid FA-HA Auth Ext)?

Yes. This seems like a more likely attack.

> changing the RFC is necessary.

Would you be opposed to changing the "SHOULD" to a "MAY" as proposed  
by George?

Thanks,
Acee

> Behalf Of
>> most

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 8 Apr 2008 09:54:52 +0100

Hi Kent et.al.,

What I am saying is two things:

1) in general sending a reply when authentication fails is bad
practice and should not be recommended by IETF RFCs. So the "SHOULD"
language is too strong. IMO it should either become SHOULD NOT, or at
MAY with a warning of the possible attack.

2) In the special case where,
    a) the HA knows for a fact that a valid FA exists (i.e., an FA-HA
AE checks out), and
    b) if the MN-HA AE fails,
it makes sense for the HA to notify the FA of that fact (presumably
using 131 code). In that case I think the RFC should say that the FA
again SHOULD NOT forward the response to the MN, or at worse MAY
forward it with a warning of the possible attack.

I think both of the above are correct but I will understand if people
do not want to both with (2), in which case we can just do (1).

I hope the above is clear but see some more below...

>  forward the RRP to the MN?

GT> No I think the FA should not forward it as I say in (1) above.

>  Or the intention is to only notify the FA and not the MN to avoid DoS

GT> Yes, exactly. The problem is of course that existing FA
implementations maybe forwarding this message by default but I think
that is fine.

>  What happens if the MN is appending the FA-HA auth ext?

GT> Then the FA-HA AE will fail and will not meet the special case
condition (2a) above so no response should be sent by the HA.

>  HA is sending the RRP.  I'm not sure what's new here.

GT> Maybe now it is clearer?

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 8 Apr 2008 09:17:09 -0500

George,

I am not sure where you are coming from on this issue! The best advice
is to "stop digging :)"

But let me say the following without addressing too many of the little
details of your attempt to change the whole Mobile IPv4 architecture to
address, IMO, a non-issue. Not only MIPv4 architecture you are trying to
change but you are proposing a new security architecture:)

RFC3344 implementations has been working for years and it works just
fine. We need to stop customizing the standard to fit certain scenario
here and there. Actually in order to be exact, certain views of handling
certain scenarios. MIP4 (RFC3344) assumes that the FA is a passive node
and all what it does (in this regard) it relays RRQ to the respected HA
or the RRP to the MN. How the FA would know then when to relay the RRP
and when NOT even those with code 131? What you are trying to articulate
is against RFC3344 architecture. May be you would like to have a new
draft out there for a new FA NOT only that but a new security
architecture. That is absolutely fine, then people will have a real
choice between what in RFC3344 and your proposal.

Please see one more comment inline.

Cheers!

Best Regards,
Ahmad

> Sent: Tuesday, April 08, 2008 3:55 AM
> To: Kent Leung (kleung)
> Cc: Mobile IPv4 Mailing List; Henrik Levkowetz; Acee Lindem
> 1) in general sending a reply when authentication fails is 
> bad practice and should not be recommended by IETF RFCs. So 
> the "SHOULD"
> language is too strong. IMO it should either become SHOULD 
> NOT, or at MAY with a warning of the possible attack.
> 
>     a) the HA knows for a fact that a valid FA exists (i.e., 
> an FA-HA AE checks out), and
> it makes sense for the HA to notify the FA of that fact 
> (presumably using 131 code). In that case I think the RFC 
> should say that the FA again SHOULD NOT forward the response 
> to the MN, or at worse MAY forward it with a warning of the 
> possible attack.

[Ahmad]
This is a very interesting security proposal!

RFC3344 made it optional to the MN and the FA to have a security
association MN-FA AE in order to secure the signaling link between the
MN and the FA (I believe for valid reasons). Later on, IETF introduced
MN-AAA AE as part of RFC3012 (RFC4721) to help resolving the same issue.
NOW: You are proposing a new mechanism where the FA relies on the MN-HA
AE to secure its link with the MN and identify bad rouge mobile node.
Wow!

As I said above, a new draft for this proposal will save a lot of people
a lot of time while at the same time keep RFC3344 SANE.

Best Regards,
Ahmad

> 
> I think both of the above are correct but I will understand 
> if people do not want to both with (2), in which case we can 
> just do (1).
> 
> implementations maybe forwarding this message by default but 
> I think that is fine.
> 
> >  Today, FA already receive error code 131 when MN-HA auth failed if 
> > the  HA is sending the RRP.  I'm not sure what's new here.
> >
> 
> >  From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of
> >
> > George Tsirtsis
> change, since 
> > this  would require FAs to understand code 131, which may 
> not do currently.
> replies  for
> >  > has the behaviour configurable, for that reason.  And as 
>  the RFC 
> > 3344
> >
> >  > and 3344bis text seems to match this usage reasonably  well, I 
> > don't  > think we want to change it?
> >  >
> >  >
> >  >         Henrik
> >  >
> > > when the registration request fails FA-HA authentication. The  > 
> > existence of the 132 reply code would imply that one should 
> always  > 
> works in  > 
> >  > I checked the RFC 3344 BIS  draft and there has been no 
> change in 
> > this  area.
> >  > > > Thanks,
> >  > > > Acee
> >  > > >
> >  > >
> >  > >
> >  >
> >  >
> >  > --

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 8 Apr 2008 15:43:30 +0100

Ahmad,

You could just say that you prefer not to change the RFC, instead of
all this nonsense about me proposing a different security
architecture.

As I said, I can understand if people do not want to bother with (2),
but at least (1) seems to be reasonable.

George

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 08 Apr 2008 17:52:55 +0200

Hi,

<hat type="regular-bozo">

> MAY with a warning of the possible attack.

I'm in favour of changing the wording to "MAY".

> forward it with a warning of the possible attack.

I'm not decided on this.  Personally, I'd like to see proposed text to
decide either way.

Regards,

	Henrik

</hat>

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 08 Apr 2008 17:57:59 +0200

Hi,

In order to follow my own advise and efforts to get issue trackers more
used in the IETF, I've added this issue to the MIP4 issue tracker:
  http://tools.ietf.org/wg/mip4/trac/ticket/6

The open issues status for documents with issue tracker entries (for
working groups that have issue trackers on tools.ietf.org) are now visible
on the WG status page:
  http://tools.ietf.org/wg/mip4

Regards,

	Henrik

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 8 Apr 2008 09:18:44 -0700

I have slight adversion to the language change.  Not because I disagree
with George's reasoning.  But on the fact that deployments and
implementations already have default behavior based on existing RFC.  So
not clear what is accomplished from the practical perspective.  Whatever
the default behavior is in the implementation, there will need to be a
knob for the alternative behavior.  So in essence, both needs to be
supported. The language change would only stir up unnecessary bickering
among vendors on whose default behavior is more right.

BTW, experience has shown that sending reply with error code 132 has
been advantageous.  The FA-HA authentication failure discovered
misconfiguration.  Have not seen any cases of DoS attack from FAs.  So I
prefer to leave the SHOULD as is.

Kent 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Acee Lindem
Sent: Monday, April 07, 2008 6:27 PM
To: Kent Leung (kleung)
Cc: Mobile IPv4 Mailing List
Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code 132
-foreignagent failed authentication

> only logging the event.  But then always runs into cases when the 
> reply was required.  So I think it's up to implementation to decide 
> the sending of the RRP or not when authentication fails.  Not sure if 

Would you be opposed to changing the "SHOULD" to a "MAY" as proposed by
George?

Thanks,
Acee

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Acee Lindem

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 8 Apr 2008 09:28:47 -0700

For #2, how does FA objectively decide if it should forward the reply to
the MN or not?  MN would like to know if its request was received or not
by the HA.  If a misconfigured-SA MN doesn't hear reply, it will send
more registration which would look more like a DoS attack.  But if it
received an error code that it failed authentication, then it could stop
and indicate to the user to call support or something.  

It seems to me that the issue you are trying to address could be an
alternative signaling from the HA to the FA when HA detects a DoS attack
(i.e. some registration/sec threshold from particular user reached).
Then the FA is explicitly made aware and can do something about it such
as shut down the L2 link.

I think embedding this DoS attack support in the normal registration
signaling may not be the ideal approach.  Not sure if my idea is any
better.  But I think 4433bis need not change to deal with the scenario.

Kent

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Tuesday, April 08, 2008 1:55 AM
To: Kent Leung (kleung)
Cc: Henrik Levkowetz; Mobile IPv4 Mailing List; Acee Lindem
Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code 132 -

Hi Kent et.al.,

1) in general sending a reply when authentication fails is bad practice
and should not be recommended by IETF RFCs. So the "SHOULD"
language is too strong. IMO it should either become SHOULD NOT, or at
MAY with a warning of the possible attack.

2) In the special case where,
    a) the HA knows for a fact that a valid FA exists (i.e., an FA-HA AE
checks out), and
    b) if the MN-HA AE fails,
it makes sense for the HA to notify the FA of that fact (presumably
using 131 code). In that case I think the RFC should say that the FA
again SHOULD NOT forward the response to the MN, or at worse MAY forward
it with a warning of the possible attack.

I think both of the above are correct but I will understand if people do
not want to both with (2), in which case we can just do (1).

> this  would require FAs to understand code 131, which may not do
currently.

>  >  Your post sums it up pretty much, but let me add this:  In some  >

> existence of the 132 reply code would imply that one should always  > 
> respond. However, this is contrary to way authentication works in  > 
> most protocols (at least routing  > protocols) and would seem to leave

> the HA more susceptible to DoS  attacks.

---

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 9 Apr 2008 13:49:20 +0100

OK, so from the various comments I get that my proposal (2) maybe
pushing things too far so I am not going to insist.

Kent, could you clarify why you do not want to soften the SHOULD
language, to at least a MAY + a warning?
It seems to me that such a change is not going to break any existing
implementations; instead it will allow any new implementations to make
more informed decision on this. Note that both SHOULD and MAY are
compatible with implementations that either send or don't send the
131/132 codes. Only if we change this to MUST/MUST NOT we would break
something, so this is only a matter of emphasis and recommendation.

Regards
George

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 9 Apr 2008 10:02:05 -0500

Hi George,
Please allow me to jump in and comment on this.

Regards,
Ahmad 

> 
> Kent, could you clarify why you do not want to soften the 
> SHOULD language, to at least a MAY + a warning?
> It seems to me that such a change is not going to break any 
> existing implementations; 
> instead it will allow any new 
> implementations to make more informed decision on this. 

[Ahmad]
Could you please explain how the change from "SHOULD" to "MAY" will make
the new implementation to make a "more informed" decision?

> Note 
> that both SHOULD and MAY are compatible with implementations 
> that either send or don't send the
> 131/132 codes. 

[Ahmad]
Okay. You seem to say that there are already existing implementation
that send 131/132 and there are some that do not. Ok. then what is the
problem?

Are we trying to find a way out for those existing implementations which
decided NOT to send these error codes probably because they believe that
they are trying to avoid replying to "what is called DoS attack"?

My apologies for referring to it as "What is called DoS attack" because
until now, I do not understand the characteristics of such DoS attack?
If we understand it, then we probably will be able to make a more
informed decision.

> Only if we change this to MUST/MUST NOT we 
> would break something, so this is only a matter of emphasis 
> and recommendation.
> 
> Regards
> George
> 
> > I have slight adversion to the language change.  Not because I 
> > disagree  with George's reasoning.  But on the fact that 
> deployments 
> > and  implementations already have default behavior based on 
> existing 
> > RFC.  So  not clear what is accomplished from the practical 
> > perspective.  Whatever  the default behavior is in the 
> implementation, 
> > there will need to be a  knob for the alternative behavior.  So in 
> > essence, both needs to be  supported. The language change 
> would only 
> > stir up unnecessary bickering  among vendors on whose 
> default behavior is more right.
> >
> > misconfiguration.  Have not seen any cases of DoS attack 
> from FAs.  So 
> > I  prefer to leave the SHOULD as is.
> >
> >
> >  Kent
> >
> >  > Isn't there a significantly higher chance of DoS attacks 
> from MNs  
> > > (i.e.
> >  > I've always preferred not to send reply when 
> authentication failed 
> > by  > only logging the event.  But then always runs into cases when 
> > the  > reply was required.  So I think it's up to implementation to 
> > decide  > the sending of the RRP or not when authentication fails.  
> > Not sure if  > changing the RFC is necessary.
> >
> > Behalf  > Of Acee Lindem  > Sent: Friday, April 04, 2008 
> 12:02 PM  > 
> > Cc: Mobile IPv4 Mailing List  > Subject: Re: [Mip4] RFC 3344 - Home 
> > Agent Registration Code 132 -  > foreignagent failed 
> authentication  >  
> > > Any opinions?
> >  > Thanks,
> >  > Acee
> >  >> With respect to our MIP4 HA implementation, we've had 
> several  >> 
> > discussions as to whether a registration reply should be 
> generated  >> 
> > when the registration request fails FA-HA authentication. The  >> 
> always  >> 
> works in  >> 
> > most  >  >> protocols (at least routing protocols) and 
> would seem to 
> > leave the HA
> >
> >  >> more susceptible to DoS attacks. I checked the RFC 3344 
> BIS draft 
> > and
> >
> >  > Supplemental site: http://www.mip4.org/  > --  > Mip4 
> mailing list: 
> > [email-masked]

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Thu, 10 Apr 2008 15:32:24 -0700

Hi George.  I mentioned the reasons in my previous email: default
implementation adhering to RFC language in deployment for years and
experience has shown usefulness of reply and lack of FA DoS attacks.
Keeping the language the same does not break anything or prevent
implementations from supporting both cases. :)

Kent

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Wednesday, April 09, 2008 5:49 AM
To: Kent Leung (kleung)
Cc: Acee Lindem; Mobile IPv4 Mailing List
Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code 132

Regards
George

On Tue, Apr 8, 2008 at 5:18 PM, Kent Leung (kleung) <[email-masked]>
wrote:
> disagree  with George's reasoning.  But on the fact that deployments 
> and  implementations already have default behavior based on existing 
> perspective.  Whatever  the default behavior is in the implementation,

> essence, both needs to be  supported. The language change would only 
> stir up unnecessary bickering  among vendors on whose default behavior
is more right.

> misconfiguration.  Have not seen any cases of DoS attack from FAs.  So

>  > I've always preferred not to send reply when authentication failed 
> Behalf  > Of Acee Lindem  > Sent: Friday, April 04, 2008 12:02 PM  > 
> Agent Registration Code 132 -  > foreignagent failed authentication  >

>  >> With respect to our MIP4 HA implementation, we've had several  >> 
> discussions as to whether a registration reply should be generated  >>

> existence of the 132 reply code would imply that one should always  >>

> respond. However, this is contrary to way authentication works in  >> 
> most  >  >> protocols (at least routing protocols) and would seem to 
> leave the HA
>
>  > Supplemental site: http://www.mip4.org/  > --  > Mip4 mailing list:

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 11 Apr 2008 10:17:13 +0100

OK Kent, I understand your position.
Regards
George