Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 4 Sep 2003 18:32:11 -0500

Hi, Pete,

Regards,
Ahmad

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Thursday, September 04, 2003 6:07 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
> 
> 
> 
> Hi, Ahmad,
> 
> Ahmad Muhanna writes:
>  > > -----Original Message-----
>  > > From: Pete McCann [mailto:[email-masked]] 
>  > > Sent: Thursday, September 04, 2003 12:42 PM
>  > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
>  > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 
> [email-masked]'  > > Subject: RE: [Mip4] RFC3012bis: Proposal 
> for Issue2-Change5  > > 
>  > > 
>  > > 
>  > > Hi, Ahmad,
>  > > 
>  > > Ahmad Muhanna writes:
>  > >  > Hi, Pete,
>  > >  > 
>  > >  > The scenario I was concerned about does not use the 
>  > > bad-authenticator in its  > response and therefore it is no 
>  > > issue.  > I agree with your text below:  > 
>  > >  > >  Note that an active attacker may try to prevent successful 
>  > >  > >  registrations by sending a large number of Agent 
>  > >  > >  Solicitations or bogus Registration Requests, each 
> of which 
>  > >  > >  could cause the FA to respond with a fresh challenge, 
>  > >  > >  invalidating the challenge that the MN is 
> currently trying to 
>  > >  > >  use. To prevent such attacks, the FA MUST NOT invalidate 
>  > >  > >  previously unused challenges when responding to 
>  > >  > >  unauthenticated Registration Requests or Agent 
>  > > Solicitations.  > 
>  > >  > With respect to the following text. I do not think that it 
>  > > is necessary.  > It is probably redandfant information.  > >  
>  > > In addition, the FA MUST NOT allocate new storage when 
>  > >  > >  responding to such messages, because this would 
> also create 
>  > >  > >  the possibility of denial of service.
>  > > 
>  > > Are you saying that if the FA doesn't invalidate previously 
>  > > unused challenges, then it will not allocate more storage?  
>  > > That doesn't necessarily follow.
>  > 
>  > Then, can you elaborate more on how this does not 
> necessarily follow.
> 
> If we remove the restriction, then it would be legal to 
> implement an FA that created a new challenge whenever it 
> received an un-authenticated RRQ or Agent Solicitation, and 
> that allocated new storage for each challenge.  This would 
> have the property of not invalidating old challenges (because 
> they would still be kept in
> storage) but would allow unauthenticated messages to exhaust 
> the resources of the FA, which would be bad.
> 

Well, what is the problem with that. 
Are we here proposing an HLD for FA or a standard.
Those things MUST be left out for implementations. If some one have a super
jet machine and an unlimited memory, why we need to restrict them.
I feel that we need to keep this out of the standard. It is not related to
the protocol we are proposing here.

> -Pete

---

From: Pete McCann <[email-masked]>
Date: Fri, 5 Sep 2003 09:42:33 -0500

Hi, Ahmad,

 > the protocol we are proposing here.

On the contrary, I think it is quite appropriate to call out such
restrictions in a standard.  See section 1.7.1 from RFC 2408:

 1.7 ISAKMP Protection

 1.7.1 Anti-Clogging (Denial of Service)

    Of the numerous security services available, protection against
    denial of service always seems to be one of the most difficult to
    address.  A "cookie" or anti-clogging token (ACT) is aimed at
    protecting the computing resources from attack without spending
    excessive CPU resources to determine its authenticity.  An exchange
    prior to CPU-intensive public key operations can thwart some denial
    of service attempts (e.g.  simple flooding with bogus IP source
    addresses).  Absolute protection against denial of service is
    impossible, but this anti-clogging token provides a technique for
    making it easier to handle.  The use of an anti-clogging token was
    introduced by Karn and Simpson in [Karn].

    It should be noted that in the exchanges shown in section 4, the
    anticlogging mechanism should be used in conjuction with a garbage-
    state collection mechanism; an attacker can still flood a server
    using packets with bogus IP addresses and cause state to be created.
    Such aggressive memory management techniques SHOULD be employed by
    protocols using ISAKMP that do not go through an initial, anti-
    clogging only phase, as was done in [Karn].

So, this text calls out some specific requirements for memory
management and its impact on security.  I think it is important that
we do the same in 3012bis, so that we will have implementations that
are not vulnerable to state exhaustion attacks.  Otherwise, we could
end up with an embarassing situation that gives the standard a poor
reputation.

-Pete

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4