Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT)

From: "Zhang, Qiang [NTK]" <[email-masked]>
Date: Mon, 6 Nov 2006 10:59:49 -0600

Pascal, 

I think it is fine to have optional RR as long as there is implementation that can benefit. 

Can we get the thread models summarized in the RR draft, I see 

	1. RR can mitigate the "redirect" of HA outbound traffic to victim server
	2. No authenticity for the route (RR will help)
      3. MITM NAT can selectively drop packets creating retransmissions, or DoS toward MN (of coz, MITM NAT can shut down the MN anyway). RR will not help on these
      4. changing of the inner CoA, so to redirect the HA->MN traffic from the MITM NAT gateway (say from the packet size etc, NAT gw can fingerprint the traffic pattern, So to let the BU/BA etc go through but reroute the other packets)
      more?

Also on the issue to ease the aCOA requirement, I think both 3775 and 3776 need to be eased as both have the context regarding the aCOA option

Qiang

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 8:00 AM
To: Soliman, Hesham; Zhang, Qiang [NTK]; RYUJI WAKIKAWA; Narayanan, Vidya
Cc: [email-masked]
Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT)

Hi Hesham:
 
This is getting confusing, maybe because of the RR term. As you very well know:

- What we are really talking about here is enabling the HA to check that the MN can be reached at the CoA, which causes an extra latency when roaming but does not involve the complexity of the test by the MN.

- What it mitigates is the redirection attack which can be used to bomb an attacked server. Such a DoS attack is difficult in IPv6 because in most cases, the MN will autoconf its address. So the bombing can only be
done against (the access of) an attacked network, not a specific host. 	
 
- There can still be a MITM. But it needs to be able to forward the BA to the MN, so it is on the way of its own attack. Combined with ESP, this leaves little room for an attacker. In other words, we are trying to have better locks than the neighbors :)
 
My point is this. We can make a simple and optional addition to the protocol where the HA asks the MN to send a second BU. If this provides an interesting improvement in the security level of the solution, why not just do it?

  Pascal

>-----Original Message-----
>From: Soliman, Hesham [mailto:[email-masked]]
>Sent: Friday, November 03, 2006 3:20 PM
>To: Zhang, Qiang [NTK]; RYUJI WAKIKAWA; Narayanan, Vidya
>Cc: [email-masked]; Pascal Thubert (pthubert)
>Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE:
[Mip6]concensus: issue 76: Alt CoA
>should not beusedwhen traversingIPv4 NAT)
>
>
>
> > I would agree the MITM attack will not compromise the security 
> > provided via Ipsec ESP but rather a DoS is possible if indeed the 
> > attacker got in the routing path/redirect.
> > Just a hypothesis that the issue can only be resolved through 
> > hop-hop security, RR will not help on the DoS, no?
>
>=> RR would certainly not help with DoS, it doesn't help with DoS
today.
>But more importantly, DoS can be done today on other protocols doing
NAT
>traversal and even on any normal communication that doesn't involve MIP 
>or NAT traversal. So solving it for this draft doesn't add anything to 
>Internet security in general.
>
>Hesham
>
> >
> > Qiang
> > -----Original Message-----
> > From: Soliman, Hesham [mailto:[email-masked]]
> > Sent: Thursday, November 02, 2006 9:22 AM
> > To: RYUJI WAKIKAWA; Narayanan, Vidya
> > Cc: [email-masked]; Pascal Thubert (pthubert)
> > Subject: RE: What are we protecting over IPv4 in DS-MIP6?
> > (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen 
> > traversingIPv4 NAT)
> >
> >
> >  > RR check can be one solution, but as other people pointed out, 
> > this  > causes additional round trip.
> >  > In addition, if there is no NAT, we can simply protect CoA by 
> > ACoA  > option.
> >
> > => This is not the issue being raised, the issue is the insecurity 
> > of the IPv4 header when a NAT exists. The outer header is obviously 
> > unprotected and vulnerable to redirection attacks (an attacker 
> > acting as a NAT bascially).
> > I don't think we need to solve that problem as I indicated in a 
> > previous email.
> >
> > Hesham
> >
> >
> >
> >  > If HA detects that the CoA is different between IPv4 header  > 
> > and ACoA,  > it can operate your RR check.
> >  > Otherwise, it should be skipped.
> >  > A new message BA-ack may be sufficient. i.e. An  > acknowledgment 
> > of BA  > sent back from  MN.
> >  >
> >  > ryuji
> >  >
> >  > On 2006/11/02, at 4:08, Narayanan, Vidya wrote:
> >  >
> >  > >
> >  > > All,
> >  > > This is something I should've raised yesterday when I read all 
> > the  > > emails, but after sleeping over it and some other  > 
> > discussions, I'm  > > still  > > confused - so, figured I should 
> > raise it now :)  > >  > > First, I don't believe that an AltCoA 
> > option (v4 or v6)  > buys anything.
> >  > > Let's look at this.
> >  > >
> >  > > In IPv4, the outer IP address is always up for  > modifications 
> > and there  > > is no way to distinguish an adversary modifying it 
> > from a NAT  > > modifying  > > it.
> > And, if the outer IPv4 source address is different from the
> > > > inner IP  > > address, there is no way for the HA to
> > figure out whether the  > > modification is due to a NAT or an 
> > adversary. Such is the  > truth with  > > NATs and there is nothing 
> > that can be done about it. Even  > if the outer
> > > > and inner IP addresses are the same, there is no way to
> > > figure out  > > that  > > they are the same because there
> > is no NAT or because a NAT-ed IP  > > address  > > in the outer 
> > header has been modified back to equal the inner IP  >
> > > address  > > by an adversary. This is quite feasible,
> > especially when the inner  > > packet is not encrypted and totally 
> > depends on the intention of the  > > attacker.
> >  > >
> >  > > The presence of the Alt-CoA option buys nothing exactly  > for 
> > the same  > > reasons. The fact that the Alt-CoA option is integrity  
> > > protected means  > > nothing, since the HA still must use the 
> > outer IP address  > as the CoA -
> > > > and there is no guarantee about that being intact.
> >  > >
> >  > > We cannot pick and choose what attacks we like and what we 
> > don't.
> >  > > Either
> >  > > we protect against redirection attacks or we don't. At
> > > this point, I'm  > > saying that integrity protection of
> > the actual CoA alone proves  > > nothing.
> >  > > Reachability checks have more value than integrity  > 
> > protection of a  > > field  > > that is allowed to be modified. 
> > Reachability checks too, in the  > > absence  > > of confidentiality 
> > on the inner packet, does not guarantee that an  > > attacker is not 
> > on the path - but, it at least proves that  > the MN is  > > 
> > reachable at that address.
> >  > >
> >  > > So, my vote would be to perform an optional reachability check 
> > and  > > document the vulnerability that may still exist.
> >  > >
> >  > > Vidya
> >  > >
> >  > > _______________________________________________
> >  > > Mip6 mailing list
> >  > > [email-masked]
> >  > > https://www1.ietf.org/mailman/listinfo/mip6
> >  >
> >  >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> >
> >

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 06 Nov 2006 09:42:22 -0800

Hello Qiang,

> Also on the issue to ease the aCOA requirement, I think both 3775 and 3776 need to be eased as both have the context regarding the aCOA option

in the context of MIPv6, as defined in RFC 3775,
where the access network and the home network are
IPv6, the use of AltCoA option is required. we
shouldn't relax the MIPv6 specs.

DS-MIPv6 can relax that requirement for mobile
nodes that are attached to an IPv4 access network.

Vijay