Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhentraversingIPv4 NAT

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 2 Nov 2006 12:17:01 +0100

Hi Hesham:

Can't we can start the discussion right now on the list so that we are
already advanced for the meeting?
I'm afraid I will not attend IETF this time so I will not be able to
defend the following proposal myself. 

Proposal:
---------

The proposal aims at checking whether the MN is actually reachable at
the COA, regardless on whether the CoA is IPv6, IPv4 or IPv4/NAT, before
accepting a BU. Another objective is to minimize the changes on existing
protocols and implementations.

1) The proposed way of doing so is a new, optional 3-way handshake. This
is achieved by ways of 2 Binding Update flows in a row.

2) The handshake is optional. The HA decides to use it whenever its
policy requires. It is recommended to use it at least if the CoA in the
Binding Update changes and if the alt COA option is not present, though
it might also be used if the alt CoA option is present, for instance if
the visited network is not trusted for owning its prefixes.

3) The HA signals to the MN that it wants to use the optional 3-way
handshake by responding with a new "additional BU required" flag in the
Binding Ack. The Binding Ack is sent to the new CoA, as found in the
source of the BU packet or in the alt CoA field if present. The Binding
Ack also contains Binding Refresh Advice with the Refresh Interval set
to 0. (alternate, what about using a status code?).

4) The HA store that new CoA as "proposed" in the BCE but waits for an
additional BU with a valid sequence counter to apply the updates
associated to the BU. 

5) Upon a Binding Ack with the new "additional BU required" flag, the MN
updates its sequence counter and triggers a new BU immediately.

6) If the CoA in a valid BU matches the current CoA or the proposed CoA
in the BCE, the HA applies the changes associated to the BU and responds
as mandated by the protocol, without the "additional BU required" flag
set.

What do you think?
	
Pascal 

>-----Original Message-----
>From: Soliman, Hesham [mailto:[email-masked]] 
>Sent: Thursday, November 02, 2006 7:43 AM
>To: [email-masked]
>Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be 
>usedwhentraversingIPv4 NAT
>
>Hi all,
>
>On the question I posted below, we got the following answer: 
>
>Yes: 5
>No: 1
>
>Other (Yes and No): 1. This was Ryuji's comment where he said 
>he would go for "Yes" if integrity is ensured.
>
>We have concensus on removing the Alt-CoA and I will post a 
>separate issue on the security aspect of this. Hopefully we 
>can resolve the security issue during IETF week. 
>
>This issue is now closed. Thanks for your feedback.
>
>Hesham
>
> > -----Original Message-----
> > From: Soliman, Hesham [mailto:[email-masked]]  > 
>Sent: Wednesday, November 01, 2006 12:11 AM  > To: Pascal 
>Thubert (pthubert); [email-masked]  > Subject: [Mip6] 
>concensus: issue 76: Alt CoA should not be  > used 
>whentraversingIPv4 NAT  >  > Pascal, all,  >  > There's been a 
>lot of emails on this issue so I think WG members are  > fully 
>informed now about what this issue involves. I will  > ask a 
>simple  > question and I'd like people to choose one of the 
>options below. To  > avoid any confusion I'm keeping the 
>question simple and clear. 
> >
> > Leaving the checksum option and integrity issue aside  > 
>(because I know we  > can fix it and I'm writing a separate 
>issue for it) please  > let give me  > an answer to the 
>following question: 
> >
> > Do you agree that the MN does not include the Alt-CoA 
>option  > in the BU  > when it is located in an IPv4-only network? 
> >
> > 1. Yes
> > 2. No
> >
> > Please include a brief reason for you answer, Pascal 
>already did so I  > don't expect another one :). As I said, 
>ignore the checksum  > issue, this  > will be handled separately.
> >
> > FWIW, I choose 1) above because it's the only way to make  
>> sure that the  > HA can detect the presence of a NAT by 
>comparing the outer  > v4 addresses  > with the IPv6 header. 
> >
> > Hesham
> >
> >
> >  > -----Original Message-----
> >  > From: Pascal Thubert (pthubert) 
>[mailto:[email-masked]]  >  > Sent: Tuesday, October 31, 
>2006 4:12 AM  >  > To: Soliman, Hesham; [email-masked]  >  > 
>Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used  
>>  > when traversingIPv4 NAT  >  >  >  > Hi Hesham:
> >  >
> >  > I agree:
> >  >
> >  > 1) with relaxing the requirement in RFC 3775 to include 
>an Alt CoA  >  > option all the time.
> >  >
> >  > 2) that the MN should omit it, as opposed to the HA  > 
>filtering it out.
> >  > The Alt CoA is the real address at which the MN is  > 
>reachable, that is  >  > what HAs implement today, that is 
>what all people in the art  >  > understand.
> >  > I want to stay simple and keep it that way.  I'd hate to 
> >  > have rules like  >  > "this is A but then if there is 
>also that then this is B  > which is the  >  > opposite of A", 
>etc... we are not lawyers! 
> >  >
> >  > 3) that we have to find an alternate way to endure that 
>the MN is  >  > reachable at the CoA, defined as the source of 
>the packet  > when the HA  >  > gets it.
> >  >
> >  > I'd also agree that:
> >  >
> >  > 4) UDP is used all the time in IPv4 roaming situation,  
>> regardless on  >  > whether NAT is detected or not. That's 
>not really in the  >  > mail but since  >  > you fixed the 
>message format in the thread to add UDP, I  >  > take 
>advantage  >  > of the exchange to raise that point again.
> >  >
> >  > I disagree:
> >  >
> >  > 5) to jump too quickly on the conclusion that the 
>checksum  >  > is the way to  >  > go. I understand that it 
>has value in certain scenarios that you  >  > mention. But it 
>fails to guarantee that the MN is reachable  >  > at the CoA  
>>  > in another common case that is NAT; and it does not  > 
>protect against a  >  > rogue DHCP server assigning you an 
>IPv4 DoS'ed address,  > which could  >  > easily happen in the 
>IPv4 world. 
> >  >
> >  > So when you call for consensus, please leave open the  > 
> > solution to 3) so  >  > we can see if there's a preferable 
>alternative. I, for one,  >  > would favor  >  > an approach 
>like 2 BU flows in row, which would emulate a 3 way  >  > 
>handshake and guarantee the reachability of the MN in all cases. 
> >  >
> >  > Pascal
> >  >
> >  >
> >  >
> >  >
> >  > >-----Original Message-----
> >  > >From: Soliman, Hesham [mailto:[email-masked]]  > 
> > >Sent: Thursday, October 19, 2006 6:19 PM  >  > >To: 
>[email-masked]  >  > >Subject: RE: [Mip6] RE: issue 76: Alt CoA 
>should not be used when  >  > traversingIPv4 NAT  >  > >  >  > 
>>Folks,  >  > >  >  > >This issue was revived mainly due to 
>Vijay points on the  >  > need for the  >  > >checksum option 
>when the alt-CoA is not used. Let me  > summarise the  >  > 
>>issues first then propose a way forward.
> >  > >
> >  > >Summary:
> >  > >--------
> >  > >
> >  > >The initial resolution for the issue suggested that we 
>add  >  > a checksum  >  > >option that includes a checksum on 
>the src and dst  > addresses in the  >  > IPv6  >  > >header. 
>This was suggested to be used when the alt-coa is  >  > not 
>present  >  > to  >  > >maintain the integrity of the src 
>address when ESP is used. 
> >  > I want to
> >  > >emphasise that this is only needed when ESP is used, 
>not with AH.
> >  > >
> >  > >Now the point that Vijay raised is also quite valid: 
>With NAT  >  > traversal,  >  > >the outer IPv4 header is 
>vulnerable, yet it is needed  > because the HA  >  > >responds 
>to that address and sets up the UDP tunnel to the outer  >  > 
>>(natted) IPv4 src address in the packet containing the BU. 
> >  > There is no
> >  > >way we can secure that address, yet, it essentially 
>acts  > as another  >  > >binding, which if modified 
>maliciously, would redirect the  >  > MN's packets  >  > >to 
>another IPv4 address. To be clear, here is the packet format:
> >  > >BU packet received by HA after passing through NAT:
> >  > >  IPv4 HDR (src=natted-v4, dst=HA-addr)
> >  > >       UDP
> >  > >         IPv6 HDR (src=v4-mapped-v6, dst=HA-addr)
> >  > >          ESP
> >  > >          DST-OPT
> >  > >          MH (BU)
> >  > >
> >  > >The HA responds with a similar packet including the BA 
>and  >  > forwards all  >  > >future packets in the UDP 
>tunnel, with the dst address  > in the IPv4  >  > >header 
>being the "natted-v4" address above.
> >  > >So essentially protecting the BU does not protect the 
>MN from  >  > >redirection attacks in this case because the 
>IPv4 header is  >  > vulnerable.
> >  > >This is an inherent problem with NAT traversal. There 
>is  > practically  >  > >nothing we can do about it.
> >  > >
> >  > >So the remaining question is: Is it worth worrying 
>about  >  > the integrity  >  > >of the BU in this case? IMHO 
>I think the answer is yes. 
> >  > Why? Two main
> >  > >reasons:
> >  > >
> >  > >1. There can be cases where the BU is sent to a local 
>HA and the  >  > >operator can guarantee that no NATs are in 
>the path. In  > this case we  >  > >would lose integrity for 
>no reason, i.e. the BU becomes  > the weakest  >  > >link. 
>This is not unusual really because an operator may  >  > 
>decide that it  >  > >will only provide the HA function within 
>its domain, which  >  > happens to  >  > >not include NATs 
>between the MN and the HA.
> >  > >
> >  > >2. We have precedence with MIPv4 and NAT traversal 
>where  > the RREQ is  >  > >still secure despite the UNSAF NAT 
>traversal.
> >  > >
> >  > >Note that the answer to 1) above may be "Use AH", but I 
> >  > prefer to not  >  > >force that on implementations that 
>do not do it today  >  > (although I would  >  > >personally 
>prefer AH in general for the BU).
> >  > >
> >  > >For these reasons, and there may be more, I prefer to 
>not  >  > take this big  >  > >decision to lose the integrity 
>for the BU.
> >  > >
> >  > >Way forward:
> >  > >------------
> >  > >
> >  > >This issue is now closed, we all agree on it, but there 
>may be  >  > >disagreement on the checksum part. So I suggest 
>that I  >  > generate a new  >  > >issue for this discussion. 
>Until the new issue is resolved,  >  > I won't add  >  > >the 
>checksum option to the draft.
> >  > >
> >  > >Feel free to send comments.
> >  > >
> >  > >Hesham
> >  > >
> >  > >_______________________________________________
> >  > >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
>

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 2 Nov 2006 03:20:13 -0800

Pascal, 

Of course the discussions and concensus will happen on the list, but
it's unavoidable that this can be discussed in the meeting. Get onto
jabber :)

Hesham 

 > From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
 > Sent: Thursday, November 02, 2006 10:17 PM
 > To: Soliman, Hesham; [email-masked]
 > Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not 
 > be usedwhentraversingIPv4 NAT
 > 
 > Hi Hesham:
 >