Subject: RE: Kuntal's comments on the split document (was: Re: [Mip6] Conclusion of the consensus call relatedtothebootstrapping I-Ds)

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 22 Aug 2006 18:26:34 -0400

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2006 3:37 PM
> To: Chowdhury, Kuntal; Alper Yegin; Basavaraj Patil; [email-masked]
> Subject: Kuntal's comments on the split document (was: Re: [Mip6]
> Conclusion of the consensus call relatedtothebootstrapping I-Ds)
> 
> Alright. If you want to discuss the split document then let's do it
(note
> change in thread header).
> 
> [KC>] Which part of my statement you found to be "emotional"? Is it
the
> "rather useless" part? In my opinion, the split scenario solution
> document has some things that are totally out of scope of mip6
> bootstrapping (e.g. the dynamic DNS update). Moreover, the HA
> bootstrapping is based on DNS query which has security issues. Anybody
> in the public internet can discover operator's HAs. This is a security
> hole that the split solution introduces. These are NOT emotional
> statements :-). I am just expressing how I feel about the split
solution
> document, that's all.
> 
> jak>> These are your opinions, and I would say they are rather
emotionally
> expressed (my opinion, of course).
> 
> jak>> The goals of the split document are different from the
intergrated
> document. The split document is primarily for enterprises and for
> businesses
> that have as their primary business providing mobility service only
(hence
> the name). Since such businesses are new, they are likely to be
> entrepreneurial. They're not going to have the time or resources to
run
> around to various different SDOs and try to force their solutions to
get
> locked into the standards. The split solution is designed to provide
them
> with interoperability. It is possible for integrated wireless service
> providers to use the split solution, of course, possibly as an
additional
> revenue generator for providing mobility service to customers that use
a
> different access network provider.
> 
[KC>] What you describe above is the scope of the split document. The
scope is unique, understood. But that does not automatically justify a
standards track RFC for the solution document. What we have is a split
scenario solution framework document _using_ IKEv2, DNS etc. So, are you
OK to make the split solution I-D an informational RFC?

> jak>> Regarding the security issues of DNS, we've been through this
issue
> a
> number of times, the draft was reviewed by SAAG (we have yet to
respond)
> and
> there was nothing said about it, so I am puzzled why you are raising
this
> canard again. We recently had a good (and I might add nonemotional)
> discussion on this list about using anycast, initiated by Jean-Marie,
and
> I've drafted some text up that will allow anycast addresses to be used
in
> DNS SRV RRs instead of the unicast addresses of the HAs, based on
> Francis's
> draft, and sent the text to Gerardo (he's on vacation at the moment).
This
> should provide some moderate protection from DoS, but it will not
protect
> completely, just as the DHCP solution won't. As I've pointed out in
the
> past, as soon as you release the address of a server to an end host,
> regardless of how it is done, all bets are off. What the end host does
> with
> that address is completely out of your control, and if the end host is
> infected with malware, you can be sure somebody's botnet will get the
> address. Or are you proposing some enhancement to the DHCP based
solution
> that will make it impossible for malware to grab a home agent's
address?
[KC>] There is a clear difference between the way HA address is
discovered in the split solution and in the integrated solution. The HA
address is _assigned_ to the MN in the integrated solution by the Home
AAA server. This ONLY happens once the MN passes authentication. So, the
chances of giving away the HA address to totally unknown entities in
this case is next to none. In case of split scenario, the HAs are
totally exposed to anyone with good or bad intention. Anyone with an IP
connection can send DNS queries to get any MSP's HA addresses and then
launch DoS attacks from his/her basement. 

It is true that once the HA address is given to an entity, if that
entity is compromised, the HA address can get out to some bad guys. But
it is not likely to happen too often. This type of security threat is
generic and not specific to mip6 bootstrapping, IMHO. If the
entity/device is compromised, other things like root-key, username, any
other cached data will also be revealed. So, it is a generic issue.

In case of split scenario, the risk of giving away the HA address to bad
guys is always there. So, the solution doesn't seem to be deployable in
public wireless networks. 

> > HL prefix etc. Integrated scenario is likely to be widely deployed,
> > where as the split scenario doesn't even have any buyer.
> >
> > jak>> I think you mean draft-jang will be widely deployed. As I
recall
> > someone posted email a while back saying that there was no plan by
any
> > other
> > SDO to adopt the integrated draft as is, just the two draft-jang
DHCP
> > enhancements.
> >
> [KC>] Unfortunately, here you are making your argument based on some
> rumor that you heard about real SDO requirements. Please use official
> liaison channels to confirm SDO requirements before posting comments
on
> the mailing list.
> 
> jak>> OK. Would any of our liasons like to comment on this? Is the
system
> architecture described in the integrated draft what your SDO is
planning
> on
> standardizing?
> 
> > So, if you want to go down this path, we will end up making both the
> > documents informational. If not both of them should remain standards
> > track.
> >
> > jak>> We're not discussing the split draft here. If you want to
> propose
> > changing it, then start a separate thread.
> >
> [KC>] We need to discuss how useful the split scenario draft is. Also
to
> be fair, we need to make a decision about informational vs. standards
> track suitability for _both_ the documents if that's what the WG ends
up
> deciding. That's what I meant to say here.
> 
> jak>> Then why didn't you start a separate thread on it? This is basic
> IETF
> courtesy. Kuntal, you've been around IETF long enough to know these
kinds
> of
> things.
[KC>] OK, I apologize for raising the issues with the split solutions
I-D late in the game. James, you did not raise all the issues that you
had with the integrated I-D until now. You have been around in IETF more
than I have been....

>             jak

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

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 22 Aug 2006 16:16:24 -0700

I have not followed this discussion from the beginning so my apologies
if this has been discussed before. 

IMHO, the problem with both the split and integrated documents is that
they are more system design documents than protocol specifications. 

I think the WG correctly decided to standardize the DHCP-option of the
integrated document separately since this is the protocol part. 
The rest of the document defines a way to use the DHCP-option together
with other IETF "tools" to build a system. The split document does the
same thing so, if there is a protocol extension to be standardized
(e.g., DNS Update mobility option) it needs to be taken out and be
standardized.

Let me remind everyone that the IETF does not build
systems/architectures unless absolutely necessary and in this case it is
not necessary since one can come up with many different ways of using
several IETF protocols to bootstrap MIP, all of which are valid.

The "system description" parts of the split/integrated documents can
then become whatever; it does not really matter since the notion of
"standards track" in the IETF does not apply to systems. As far as I am
concerned, if they need to be standardized at all, they need to be
standardized in an SDO otherwise informational or BCP can work too.

Regards
George

> From: Chowdhury, Kuntal [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2006 6:27 PM
> To: James Kempf; Alper Yegin; Basavaraj Patil; [email-masked]
> Subject: RE: Kuntal's comments on the split document (was: Re:
> [Mip6]Conclusion of the consensus call relatedtothebootstrapping I-Ds)
> 
> 
> 
> "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: "James Kempf" <[email-masked]>
Date: Wed, 23 Aug 2006 10:03:13 -0700

jak>> I think there is a difference in the documentation approach that the 
split document and the intergrated document have taken. From the beginning, 
the design team and authors have agreed that the split document should 
remain one unit, for ease of reference and implementation. The protocol 
enhancements described in Section 8 must be Standards Track, the rest of the 
material on system architecture is unique IETF architecture, and needs to be 
described in a Standard Track document for interoperability reasons. 
Documents are supposed to be Standards Track if their content is critical 
for interoperability.

jak>> On the other hand, the authors of the integrated document have argued 
from the beginning that it should be split up into in separate pieces, each 
an individual Standards Track document, with the various DHCP protocol 
enhancements in the pieces. If that is the case, why aren't the DHCP 
enhancements in Section 3.5 in a separate Standards Track document? It 
doesn't make any sense to me. Looking at it as a customer of the integrated 
solution, does it make sense to you?

jak>> Regarding the system architecture in the rest of the document,  I do 
question the wisdom of including system architecture from other SDO's 
standards in IETF Standards Track document, unless they conform closely to 
what is IETF architecture. Whose system architecture will be in the 
document, 3GPP, 3GPP2 or Wimax Forum? Are they all the same? Is IETF going 
to come up with something that is completely different from all three, and 
therefore is never really deployed in the form it is in the document? The 
other SDOs are going to use the DHCP options in their own system 
architectures, and these may or may not interoperate with each other, but 
the other SDOs don't need to care because their systems are only for their 
members. So I don't see such a pressing interoperability need for a 
Standards Track document for the integrated case.

 jak>> In the end, don't really care whether the integrated document is 
Standards Track or not, but I think a document philosophy should be applied 
consistently when a particular body of work is being documented in the IETF.

jak>> Kuntal, you've completely ignored what I said, and the basic design of 
the split protocol. What I said and what the protocol does is:

jak>> 1) In response to Jean-Marie's request, we're incorporating a means 
whereby the HA address can be assigned via an anycast intermediary. This 
reduces the ease by which an adversary can obtain the HA addresses, but it 
does not remove the threat of DoS attack due to malware, just as for the 
integrated case.
jak>> 2) In the split scenerio, authentication for MSP service is performed 
during the IKE transaction. It is like any other Web service, and is not 
integrated with network access authentication. This is a basic aspect of how 
the split scenerio works: the ASP and MSP are different service providers 
(or different services provided by the same company) and so they must be 
authenticated separately.

jak>> Please go back and read the protocol design document and problem 
statement before posting these kinds of baseless comments.

jak>> If you think this is "unlikely to happen often", let me send you the 
contents of my spam folder. Today I got email from the following people:

jak>> Cleo Lindsey, Suzanne Thibault, Jeff Orr, John Bourne, 
[email-masked], ... and maybe another 100 or so additional offers from 
people I don't know and have no interest in having heard from.

jak>> Now, how did those people get my email address? Presumably all of 
these people were fully authenticated with their service providers, just as 
you claim would be the case in the integrated bootstrapping solution. Why 
are they sending me this email?

jak>> If you think that the various criminal groups who are sending spam 
aren't going to start harvesting home agent addresses and mounting DoS 
attacks on wireless service providers for blackmail I have a bridge I'd like 
to sell you.

jak>> You are right that it is a generic problem, but service providers have 
to deal with it regardless of the type of bootstrapping that is used. 
Asserting that DHCP provides any more or less protection is misleading. The 
threat must be mentioned in the Security Considerations section, and it is 
mentioned in the split scenerio Section 9.

jak>> The only issue I have is, like I said above, that a documentation 
philosophy should be applied consistently to a body of work. If the 
philosophy is "protocol enhancements in separate Standards Track documents" 
then I think that should apply to all protocol enhancements.

            jak

PS: Isn't it a bit ironic that the authors of the split document want to 
have the document be integrated and the authors of the integrated document 
want it to be split? :-)

---

From: "James Kempf" <[email-masked]>
Date: Wed, 23 Aug 2006 10:38:26 -0700

George,

The problem is that interoperability requires standardizing more than bits 
on the wire. If one MSP deploys, for example IKEv2 home address assignment 
and another doesn't then a client that is expecting to get its home address 
via IKEv2 won't know that it can for all MSPs. Unlike the integrated 
solution, no other SDO is going to take and standardize a system 
architecture based on the protocol enhancements in the split solution.

            jak

----- Original Message ----- 
From: "Tsirtsis, George" <[email-masked]>
To: "Chowdhury, Kuntal" <[email-masked]>; "James Kempf" 
<[email-masked]>; "Alper Yegin" <[email-masked]>; 
"Basavaraj Patil" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 22, 2006 4:16 PM
Subject: RE: Kuntal's comments on the split document (was: Re: 
[Mip6]Conclusion of the consensus call relatedtothebootstrapping I-Ds)

Regards
George

of
Corp.
of
or
not
message
Thank

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 23 Aug 2006 10:54:42 -0700

SDOs are by definition defining architectures relevant only to that
specific SDO. Traditionally SDOs have strived to be incompatible. More
recently there are uncertain steps towards commonality but we will see
how far this can go.

We should also not confuse what one or more SDOs may decide to do with
what is good for the Internet as a whole. MIP is not only used by
systems defined in SDOs, but also by systems used in corporate and other
systems that Net Admins put together as they see fit based on tools
available to them by the IETF and the market.

Let me also repeat that I have no problem with BCP/Info type documents
defining how these tools can be put together in certain cases.

George

> Sent: Wednesday, August 23, 2006 1:38 PM
> To: Tsirtsis, George; Chowdhury, Kuntal; Alper Yegin; Basavaraj Patil;
> [email-masked]
> Subject: Re: Kuntal's comments on the split document (was: Re:
> > > that address is completely out of your control, and if the end
host
> is