Subject: Using "a bit" as a protection against bidding down / for something

From: JJ Behrens <[email-masked]>
Date: Fri, 5 Apr 2002 15:26:07 -0800

I have a couple of comments / requests for clarification concerning this 
draft:

As hinted in the draft [section 1], these future attacks are less urgent than
vulnerabilities in ND.  Nonetheless, it is assumed that these vulnerabilities
should be fixed now (which seems like good policy).  However, when we do 
become able to fix ND, I imagine we'll be better equiped to solve these
vulnerabilities as well.  I'm not necessarily stating we should give up, I'm
just saying that we have a backup plan.  Afterall, "It's easier to build a 4
inch lens and then a 6 inch lens then it is to build a 6 inch lens."  
Furthermore, since we do have a backup plan, there's no need for desperate 
measures.

In the paragraph right before 2.1.1, Mallory is assumed to have overtaken a 
router.  However, if Mallory is capable of this, there are plenty of other 
nastier exploits that it can use.

It seems that the general bidding down problem is harder to solve than the 
specific case of mobility when the the tunnel between the MN and HA is
encrypted [page 9].  Since this tunnel SHOULD be encrypted, perhaps we 
shouldn't go to great pains to solve the other cases.  Namely, those wishing
to not encrypt the tunnel between the MN and HA probably have recourse to 
other techniques for security.  Also, since there appear to be no obvious
solutions for the *general* bidding down problem, perhaps we should leave it 
unsolved until we get another concrete example of it.

It seems difficult to imagine a "real-world" instance where the MN would 
request to use strong security, but be willing to accept weaker security
(thus making itself susceptible to bidding down).  At the very least, this 
decision should be something that the user is aware of (in the same way he is 
aware when SSL is being used by a Web browser).

In section 3.2, number 4, perhaps someone could summarize the statement, 
"raises intellectual property concerns whose implications are not clear."  I 
apologize for not being aware of these concerns.

The second to last paragraph of page 13 is far too short.  It doesn't
answer the case where Mallory acts as a NAT (translating Alice's address 
in both directions, as Tony Hain has mentioned multiple times).  Perhaps there
are assumptions that I'm not aware of, but it'd be helpful if these were 
placed in this paragraph.

Thank you all for your patience.

-jj

-- 
Users of C++ should consider hanging themselves rather than shooting their 
legs off--it's best not to use C++ simply as a better C.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------